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ABSTRACT 


Program Managers (PMs) need insight into the high-risk and high-cost elements 
of their programs to effectively manage them. The Department of Defense (DoD) has 
adopted several acquisition reform initiatives in order to become a smarter, more 
efficient, and more responsive buyer of goods and services that meet our warfighter’s 
needs. DoD Regulation 5000.2-R requires PMs to tailor a work breakdown structure 
(WBS) for each program using the guidance in Military-Handbook-881 (MIL-HDBK- 
881), "DoD Handbook - Work Breakdown Structure." This research concludes that a 
WBS structured in accordance with MIL-HDB-881 can significantly impede 
implementation of DoD acquisition reform initiatives. It does not adequately identify the 
key products and processes essential for program success. An alternate method of 
constructing a WBS was developed which better identifies and differentiates key 
products and processes. This research concludes that the alternate WBS has the potential 
to significantly facilitate implementation of recent DoD acquisition reform initiatives, as 
well as the potential to provide PMs greater visibility and early identification of cost, 
schedule, performance, and risk issues using an Earned Value Management System 
(EVSM). 
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I. 


INTRODUCTION 


A. PURPOSE 

During the past decade, defense acquisition reform has 
been very intense. The Department of Defense (DoD) has 
adopted several acquisition reform initiatives in order to 
be a smarter, more efficient, and more responsive buyer of 
goods and'services that meet our warfighters' needs. The 
effectiveness of those acquisition reform initiatives may be 
dependent on the program and contract work breakdown 
structure (WBS). DoD Regulation 5000.2-R, "Mandatory 
Procedures for Major Defense Acquisition Programs (MDAPS) 
and Major Automated Information System (MAIS) Acquisition 
Programs," requires program managers (PMs) to tailor a 
program WBS for each program using the guidance in Military- 
Handbook-881 (DoD, January 98). MIL-HDBK-881, "DoD Handbook 
- Work Breakdown Structure," presents guidelines for 
preparing, understanding, and presenting a WBS. The purpose 
of this thesis research is to analyze how MIL-HDBK-881 can 
facilitate or impede acquisition reform initiatives. 
Additionally, this research will consider acquisition reform 
initiatives that may be affected by the WBS, the uses of the 
WBS, how to develop a WBS, and an alternative method to 
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structure the WBS to more effectively facilitate or 
implement acquisition reform initiatives. 

B. BACKGROUND 

A WBS provides a consistent and visible framework for 
defense materiel items and contracts within a program. The 
WBS provides the basis for communication throughout the 
acquisition process. It is the common link, which unifies 
the planning, scheduling, cost estimating, budgeting, 
contracting, configuration management, and performance 
reporting disciplines (DoD, January 1998). The WBS is a 
product-oriented family tree composed of hardware, software, 
services, data, and facilities. The family tree results 
from systems engineering efforts during the acquisition of a 
defense materiel item. The challenge in developing a WBS is 
to balance the program definition aspects of the WBS against 
its data-generating aspects. 

MIL-HDBK-881, dated 2 January 1998, is a conversion of 
Military-Standard-881 {MIL-STD-881), "Work Breakdown 
Structures for Defense Materiel Items," with no substantive 
changes in WBS definition (DoD, January 1998). During the 
past decade, there have been several acquisition reform 
initiatives to streamline the DoD acquisition management 
process. Some of these acquisition reform initiatives are 
implemented through or affected by the WBS, which further 
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increases the challenge to balance the program definition 
aspects of the WBS. As a DoD civilian with fifteen years of 
DoD acquisition experience in US Army Program Management and 
Research, Development, and Engineering offices, the 
researcher has developed poorly-written WBSs and as a result 
suffered the consequences of attempting to manage with 
meaningless data. This first-hand experience of attempting 
to balance the program definition aspects of the WBS with 
its data-generating aspects, in addition to acquisition 
reform initiatives, prompted further exploration. 

Many of the assertions and conclusions in this thesis 
are based on experiences and discussions with Government and 
contractor personnel during my career. Mr. Lawrence Nee and 
Mr. Richard Ess of the US Army Project Manager for Mines, 
Countermine, and Demolitions have provided me with 
invaluable insight to managing programs from a DoD 
perspective. Mr. Jim Bob Bryant and Mr. Kent Jacobson of 
then Tracer Aerospace have provided me with invaluable 
insight to managing programs from a contractor's 
perspective. I have attempted to implement many acquisition 
reform initiatives and have been frustrated by not being 
able to effectively implement them. I have managed and 
participated in an Integrated Product and Process 
Development (IPPD) environment participating in Integrated 


3 



Product Teams (IPTs). I have participated in an Alpha 
Contracting process. Many of the assertions and conclusions 
in this thesis are a result of discussions during IPT 
meetings and the Alpha Contracting process. 

Part of the assertions and conclusions in this thesis 
are a result of the various acquisition and management 
courses taken while attending the US Naval Postgraduate 
School (NPS). I will be graduating soon and re-entering the 
acquisition workforce, charged with managing and executing 
US Army acquisition programs. My personal objective for 
this thesis was to integrate the lessons learned from the 
various NPS courses as well as to integrate them with my 
acquisition experience. 

C. RESEARCH QUESTIONS 

1. Primary Question 

To what extent does MIL-HDBK-881 facilitate or impede 
execution of acquisition reform initiatives? 

2. Subsidiary Questions 

a. What acQuisition reform initiatives does the 
WBS affect? 

b. What are the possible uses of the WBS? 

c. What does the project manager need to 
consider when structuring a WBS? 
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d. Is there an alternative method(s) to 

structure the WBS that will allow better 
execution or implementation of acquisition 
reform initiatives? 

D. METHODOLOGY 

My research began with a literature review of DoD 
regulations, directives, handbooks, web-sites, magazine 
articles, CD-ROM systems, and other library infoimiation. A 
thorough review of MIL-HDBK-881 and other DoD publications 
was conducted. The WBSs along with the definitions 
presented in MIL-HDBK-881's Appendices were analyzed to 
determine if WBSs developed in accordance with guidance 
contained in MIL-HDBK-881 facilitated or impeded acquisition 
reform initiatives. Based on these findings, an alternative 
method to structure the program WBS was developed. Finally, 
the alternative program WBS was analyzed to determine if the 
new WBS facilitated or impeded acquisition reform 
initiatives. 

E. ORGANIZATION OF STUDY 

This thesis is divided into five chapters. The next 
chapter provides background information and discussion of 
acquisition reform initiatives implemented through or 
affected by the WBS. Chapter III provides background 
information and discussion of MIL-HDBK-881. This chapter 
discusses the possible uses the WBS. It also discusses the 
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preparation of the program WBS and contract WBS, along with 
challenges a project manager must consider during the 
development of the WBS. This includes methods to 
incorporate or effectively implement acquisition reform 
initiatives. 

Chapter IV analyzes a program WBS developed in 
accordance with the guidance contained in MIL-HDBK-881, to 
determine to what extent MIL-HDBK-881 facilitates or impedes 
execution of acquisition reform initiatives. Chapter IV 
also determines an alternative method to structure the 
program WBS that will allow better execution or 
implementation of the acquisition reform initiatives. It 
then analyzes the new program WBS to determine to what 
extent MIL-HDBK-881 facilitates or impedes execution of 
acquisition refoirm initiatives. Chapter V concludes the 
thesis study by summarizing the findings, answering the 
research questions, and presents both recommendations for 
DoD project managers and areas for future research. 

F. BENEFITS OF THE STUDY 

The initial benefit of this study is that DoD project 
managers and students of DoD acquisition will be able to 
better understand the WBS and how it can benefit them during 
cost, schedule, and performance risk management. The second 
benefit is to identify methods to structure the WBS that 
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will allow DoD project managers to more effectively execute 
acquisition reform initiatives and ultimately save the 
taxpayer money. Finally, this study will provide beneficial 
comments such as recommendations, additions, or deletions 
and any pertinent data, which may be of use in improving 
MIL-HDBK-881. 
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II. ACQUISITION REFORM INITIATIVES 


A. INTRODUCTION 

Defense spending has decreased in real teinns since 
1985, causing DoD to rethink how it does business. 
Acquisition reform is a basic restructuring of the way the 
DoD does business. The goal of acquisition reform is to do 
the job better, faster, and cheaper. The focus has been to 
reduce the cost of the acquisition process by reengineering, 
consolidation, increased competition, and elimination of 
activities that are not cost-effective or necessary, i.e., 
value added. The DoD has been adopting modern business 
practices to achieve world-class standards of performance; 
streamlining organizations to reduce redundancy and maximize 
synergy; applying market mechanisms to improve quality, 
reduce costs, and respond to customer needs; and reducing 
excess support structures to free resources and focus on 
core competencies (Cohen, 1997). We must provide the 
warfighter what is needed, when it is needed, and at the 
best available price, while keeping the public trust in the 
acquisition process by exercising good judgment and adhering 
to the highest standards of honesty and professionalism 
(Department of the Army (DA), 1999). 


9 



The private sector has been changing their way of doing 

business to operate more efficiently in order to be 

competitive in a global marketplace. Secretary of Defense 

William S. Cohen wrote: 

For too long, DoD has labored under support 
systems and business practices that are at 
least a generation out of step with modern 
corporate America. DoD support systems and 
practices that were once state-of-the-art are 
now antiquated compared with the systems and 
practices in place in the corporate world. 

Other systems grew up in their own defense- 
unique culture and never did correspond with 
the best business practices of the private 
sector. This cannot and will not continue. 

(Cohen, 1997) . 

The Defense Reform Initiative (DRI) addresses the DoD 
corporate vision of igniting a revolution in business 
affairs within DoD that will bring to the Department, 
management techniques and business practices that have 
restored American corporations to leadership in the 
marketplace (Cohen, 1997). The DoD has been eliminating 
barriers that will allow the use of good business judgment. 
They have been providing tools to the workforce, to 
implement smarter ways of doing business. The DoD has been 
adopting many of these successful commercial practices. 

There is not a consolidated list of all the acquisition 
reform initiatives. The DoD Regulation 5000.1 and DoD 
Regulation 5000.2-R have been modified to incorporate many 
of the acquisition reform initiatives. The WBS does not 
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affect all of the acquisition reform initiatives. This 
chapter provides background information and discussion of 
acquisition reform initiatives implemented through or 
affected by the WBS. 

B. ACQUISITION REFORM INITIATIVES 

1. Streamline Acquisition/Adoption of Commercial 
Practices 

Vice President Al Gore stated, "Government should 
emulate the best in business, learn from them, and adopt 
their best business practices." He also stated, 

"Information technology is changing everything from the way 
we buy equipment to the way we fight" (Kozaryn, 1998). The 
main focus of streamlined acquisition and adoption of 
commercial practices has been to reduce cycle-time (i.e., 
shortening development and fielding cycles for new 
technology) and change from oversight to insight. This will 
help to reduce overhead and life-cycle costs. Reducing 
cycle-time will allow advance technology to be fielded 
before it is outdated. We can no longer afford to develop 
systems for ten to fifteen years or longer. We must field 
technology while it is still advanced and provides our 
military the technological advantage over our enemies. One 
commercial practice is incremental product improvements with 
short cycle-times and continued research and development 


11 



efforts on technological advancements which can be inserted 
rapidly when proven (Gansler, 1998) . The use of Advanced 
Concept Technology Demonstrations (ACTDs) and the Army's 
Fast Track Acquisition Program are other techniques to 
shorten cycle-times and make incremental product 
improvements. 

With oversight management, PMs and Milestone Decision 
Authorities (MDAs) did not have the necessary information to 
understand program status to make informed decisions in a 
timely manner. This wasted valuable resources, i.e., time 
and money, by not making timely decisions. DoD cannot 
afford to rework or fix mistakes that could have been 
eliminated through early and continuous insight to resolve 
major issues. It is easier to change paper early in the 
acquisition process than changing hardware later in the 
acquisition process. More knowledge shared between PMs, the 
Users, Government personnel, and contractors during the 
acquisition process will help to reduce asstimptions and 
decrease the amount of rework, saving DoD money. It is 
markedly cheaper to do the right thing the first time. DoD 
Regulation 5000.1 encourages PMs to continually search for 
innovative practices that reduce cycle-time, reduce cost, 
and encourage teamwork. Teamwork will be discussed in the 
next section. In addition, DoD Regulation 5000.1 requires 
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continuous focus on implementing major improvements 
necessary to streamline the acquisition process, reduce 
infrastructure, and enhance customer service through process 
reengineering and technological breakthrough. Techniques to 
reduce oversight include eliminating all but the most 
essential data requirements, obtaining access to the 
contractor's own management data, the use of commercial-off- 
the-shelf (COTS) hardware and software, and the use of 
contractor logistics support. 

DoD Regulation 5000.1 states, "In all cases, no more 
than two levels of review shall exist between a PM and the 
MDA." DoD has streamlined the acquisition management 
structure to clearly define the lines of responsibility, 
authority, and accountability. This has minimized reporting 
requirements to only the necessary information for decision 
authorities to understand program status and make informed 
decisions in a timely manner. The MDA may tailor the 
acquisition process, including program dociamentation, 
acquisition phases, the timing and scope of decision 
reviews, and decision levels (DoD, March 1998). Tailored 
approaches to oversight and review are based on a program's 
size, risk, and complexity. PMs need insight to actively 
manage the program's cost, schedule, performance, and risks. 
They can do longer afford to be risk-averse and must 
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actively work with the Users and contractors to conduct 
tradeoffs between cost, schedule, performance, and risk. 
Risk management encompasses identification, mitigation, and 
continuous tracking, and control procedures that feed back 
through the program assessment process to decision 
authorities (DoD, 1999), 

On 24 November 1997, the US Army Aviation and Missile 
Command's Acquisition Center for Missile Logistics 
Procurement Directorate received the Hammer Award for 
efforts to streamline operations and cut costs. Vice 
President Al Gore asserted in a videotaped statement, "You 
cut lead time by 45 percent, which translates to a cost cut 
to taxpayers of 500 million dollars" (Valine, 1998). DoD is 
adopting business practices to streamline business and 
improve efficiency. This is especially prevalent with 
procurement practices. Adoption of commercial practices 
enables suppliers to efficiently conduct business with the 
Government in a manner similar to that used with their 
private-sector customers. This includes the use of 
information technology and electronic commerce, use of 
common processes, use of simplified acquisition procedures 
and credit cards, use of Single Process Initiatives (SPI) 
(discussed later), simplified acquisition oversight 
procedures, best-value acquisition, oral presentations. 


14 



paperless procurement, multi-year contracting, and 
Government-industry partnerships. Past performance is used 
as a prime indicator of the risk of non-performance. 

Allowing the contractor to be responsible for configuration 
management reduces the amount of oversight and allows the 
contractor to more quickly modify their design. Another 
practice of reducing oversight is the choice of contract 
type, incentives, or warranties, to transfer or share risk 
with the contractor. 

2. Integrated Product and Process Development 
(IPPD)/Integrated Product Team (IPT) 

In May of 1995, Secretary of Defense William Perry 
directed the use of IPPD concepts and the use of IPTs in DoD 
acquisition (Perry, 1995). The use of IPPD and IPTs were 
later incorporated into DoD Regulation 5000.1 and DoD 
Regulation 5000.2-R. IPPD is a management technique that 
simultaneously integrates all acquisition activities through 
the use of multidisciplinary teams (i.e., IPTs) starting 
with requirements definition through production, 
fielding/deployment, and operational support to optimize the 
design, manufacturing, and supportability processes (Perry, 
1995). The IPPD approach is driven by the customer's need. 
The use of IPPD offers the potential to provide better 
products in less time and cost. IPTs enable both insight 
into major issues early and making the right decision at the 
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right time. The IPT concept was intended to replace the 
sequential acquisition process characterized by "throwing it 
over the wall." This sequential process required frequent 
reviews and normally resulted in substantial modifications 
or rejection of the product. The sequential review and 
approval process takes considerably longer time than an IPT 
approach that simultaneously takes advantage of all members' 
expertise and produces an acceptable product the first time. 
(Office of the Under Secretary of Defense for Acquisition 
and Technology (USD(A&T)), 1995). 

IPTs function in a spirit of teamwork with participants 
empowered and authorized, to the maximxim extent possible, to 
make commitments for the organization or the functional area 
they represent. IPTs are composed of empowered 
representatives (stakeholders) from all of the functional 
areas working together to build successful and balanced 
programs, identifying and resolving issues, and making sound 
and timely decisions. IPTs enable decision-makers to mhke 
the right decisions at the right time. IPTs are composed of 
personnel from program management, engineering, 
manufacturing, test and evaluation, logistics, safety, 
financial management, contracting including contract 
administration, contractors, suppliers and the most 
important, the customer (Perry, 1995). 
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IPTs are divided into three layers, an Overarching IPT 
(OIPT), Working IPTs (WIPTs), and Program IPTs. Figure 2.1 
shows the IPT structure. The OIPT and the WIPTs, facilitate 
building more successful and affordable programs, resolve 
problems, and gain early insight for program insight. DoD 
Regulation 5000.2-R requires an OIPT and at least one WIPT. 
WIPTs focus on a particular topic such as cost/performance, 
test, or contracting. An Integrating IPT (IIPT), which is a 
WIPT, coordinates WIPT efforts and cover all topics not 
otherwise assigned to another IPT. The IIPT supports the 
development of strategies for acquisition and contracts, 
cost estimates, evaluation of alternatives, logistics 
management, cost-performance tradeoffs, etc. Participation 
in IPTs is the primary way for any organization to 
participate in a program. Mandatory guidance relating to 
these types of IPTs can be found in DoD Regulation 5000.2-R 
(Office of the USD(A&T), 1995). 

Program IPTs are established to manage program 
execution. They perform the program tasks. The integration 
of contractors with the Government occurs primarily at this 
level. IPTs are usually formed around the key products and 
processes associated with the program. The WBS is based on 
the key products and processes in a product-oriented tree 
structure. The program IPTs are usually structured using 
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Figure 2.1. BPT Structure (Extracted from Defense Systems Management CoUege (DSMC), Systems 

Engineering Fundamentals) 

the WBS and designed to provide the maxim\im vertical and 
horizontal communication during the development process as 
shown in Figure 2.2 (DSMC, October 1999). 

There are different levels of Program IPTs. Level one 
is normally a program management IPT and a system IPT. The 
next level is either product or process IPTs. Additional 
levels may exist based on subsystems, components, or sub¬ 
processes . It is critical that these IPTs be a cohesive 
product/process team that functions efficiently and 
effectively. Each IPT has a mission to develop and deliver 
a product and its associated processes. At the program 
level, IPTs are responsible for a product or process, 
authority over the resources and personnel, an agreed 
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Figure 2.2. IPT Structure based on the WBS (Extracted from DSMC, Systems Engineering 

Fundamentals) 

schedule for delivery of the defined product, an agreed 
level of risk to deliver the defined product, and an agreed 
upon set of measurable metrics (Office of the USD(A&T), 
1998). Each program IPT functions as a small program with 
the IPT leader serving as the PM. They are given a budget, 
schedule, perfoinnance requirements, and levels of risk. An 
IPT Charter documents the above. The IPT Charter is 
essential and must be agreed upon by management and team 
members (Office of the USD(A&T), 1998) . The IPT Charter 
should clearly describe the mission and goal supplemented 
with a project timeline; team members and their authority 
and accountability; and the resources they control and team 
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deliverables. If a program deviation or a breach occurs to 
the agreed to thresholds, they are raised to the next 
higher-level program IPT to be resolved. 

The activities relative to a system's acquisition 
change and evolve over its life-cycle. The roles of various 
IPTs and IPT members evolve as well. When the team is 
dealing with an area that requires a specific expertise, the 
role of the member with that expertise will predominate; 
however, other team members' input should be integrated into 
the overall life-cycle design of the product. Some teams 
may assemble to address a specific problem and then become 
inactive or even disband after accomplishing their tasks 
(Office of the USD(A&T), 1998). 

The DoD Guide to IPPD lists the following ten 
interrelated tenets inherent in IPPD: 

1. Customer Focus 

2. Concurrent development of products and processes 

3. Early an continuous life-cycle planning 

4. Maximize flexibility for optimization and use of 
contractor approaches 

5. Encourage robust design and improved process 
capability 

6. Event-driven scheduling 

7. Multidisciplinary teamwork 

8. Empowerment 

9. Seamless Management Tools 

10. Proactive identification and management of risk 
The Rules of the Road, A Guide for Leading Successful 
Integrated Product Teams lists the following ground rules 
for implementing IPTs: 
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• Open discussions with no secrets. 

• Qualified, empowered team members. 

• Consistent, success-oriented, proactive 
participation. 

• Continuous, "up-the-line" communications. 

• Reasoned disagreement. 

• Issues raised and resolved early. 

The two most important characteristics of IPTs are 
cooperation and empowerment. IPTs must have full and open 
discussions with no secrets, working toward common goals. 
All members must be able to speak for their superiors and 
not be overturned later. IPTs with Government and 
contractor members must have a relationship of partnership 
and mutual trust versus an adversarial relationship (DoD, 
1995) . 

A successful IPT works together pulling each member's 
knowledge, skills, and attitudes through the spirit of 
cooperation. DoD IPPD HDBK lists the following principles 
that must exist for team unity. 

• All team members must be stakeholders in the mission 
of the group. 

• All team members must be empowered and capable in 
their functional discipline. 

• All members must feel free to make suggestions. 

• Members must trust one another, especially when 
sensitive issues surface. 

• The team must desire consensus and remain focused on 
team goals. 

• All members must actively seek win-win solutions to 
problems. 
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All IPT members are equal and have a vote on all issues. 

The goal is to obtain team consensus on all issues. There 
can be disagreement on how to approach a particular issue, 
but that disagreement must be reasoned disagreement based on 
an alternative plan of action rather than unyielding 
opposition (Perry, 1995). Team members must be willing to 
live with the solutions, even though the solution is not 
their first choice. 

3. Cost As An Independent Variable (CAIV) 

With today's lower defense budgets, acquisition 
managers are faced with fiscal constraints in an environment 
of interests competing for limited resources. Cost and 
schedule pressures along with changes in requirements, 
technology, laws, and policies require acquisition mangers 
to constantly tradeoff between these competing interests. 

We cannot afford all that we would like to do, so we must 
decide what is not going to be accomplished. PMs conduct 
cost, schedule, and performance risk management on a daily 
basis. Cost as an independent variable (CAIV) is a 
management technique emphasizing the cost or unit price as a 
constant. Once the system performance and objective cost 
are decided (on the basis of cost-performance tradeoffs), 
the acquisition process makes cost more of a constraint, and 
less of a variable, while obtaining the needed military 


22 



capability of the system (Defense Acquisition Deskbook 
(DAD), CAIV Working Group Report, 1999). DoD Regulation 
5000.1 states that cost must be viewed as an independent 
variable. It further states that acquisition mangers shall 
establish aggressive but realistic cost objectives for all 
programs and follow through by trading off performance and 
schedule, beginning early in the program (when the majority 
of costs are determined), to achieve a balanced set of 
goals, based on guidance from the MDA. DoD Regulation 
5000.2-R states that cost objectives shall also be set to 
balance mission needs with projected out-year resources. 

PMs must actively manage risks to obtain those cost, 
schedule, and performance objectives. 

CAIV enables PMs to refine the requirement, consider 
cost early, and make tradeoffs between performance and cost 
to obtain an affordable, mission-effective system in the 
end. In, the past, meeting the threat dictated an emphasis 
on performance and created a culture in which cost and 
schedule were adjusted to achieve the desired outcome. CAIV 
forces IPTs to determine cost drivers early and to address 
them promptly. New programs that employ CAIV from the 
beginning have the potential to generate from thirty to 
fifty-percent savings in total life-cycle costs, and ten to 
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twenty-percent savings for existing programs in later 
acquisition stages (Hoeper and Kern, 1999). 

CAIV requires the user to be an active and strong 
participant in the acquisition process since CAIV enables 
PMs to refine the requirements. The user must be active in 
the IPTs throughout the program, during the establishment 
and adjustment of program goals, particularly in the cost- 
performance tradeoff process. These tradeoffs have the 
potential to empower the user to make choices that provide 
the best performance-for-the-money for each system, thereby 
helping to ensure maximum benefit from all systems across 
the force within the resources available. CAIV may require 
larger investments early in the program in order to realize 
long-term savings in production and operation and support 
costs (DAD, CAIV Working Group Report, 1999) . 

CAIV requires the user to state system requirements in 
a few broad, top-level performance terms. These performance 
requirements are stated as threshold values, the minimum 
level required by the user, and objective values, 
representing a relevant improvement over the threshold. It 
also requires the user to establish a few Key Performance 
Parameters (KPP). The KPPs are those requirements that may 
not be traded off (Higgins, 1999). Failure to meet a KPP 
threshold will cause the MDA to reevaluate the concept or 
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system and to reassess the program. Those broad 
requirements facilitate CAIV by allowing the requirement to 
be satisfied in many different designs or approaches. This 
allows the PM and contractor to focus on the real 
warfighting requirements in the most affordable methods. 

CAIV actually increases the probability of fully meeting the 
requirements. This is true because with ample trade space 
available to the designer, intelligent trades can be 
affected quickly and efficiently to trade lower-level 
requirements to meet the top-level KPPs and meet or reduce 
costs (Higgins, 1999). Lower cost designs are typically 
both simpler and therefore easier to manufacture, and more 
reliable because the designers find themselves forced to 
invest more heavily in the intellectual challenges of 
developing creative designs to meet the cost criteria 
(Higgins, 1997) . 

4. Total Ownership Costs 

DoD Regulation 5000.1 requires acquisition programs be 
managed to optimize total system performance and minimize 
the cost of ownership. What are "total ownership costs?" 
Total ownership costs are the total life-cycle cost (LCC). 
LCC is the total cost to the Government of a program over 
its full life of developing, producing, deploying, 
supporting, and disposing of a system. LCC is all costs 
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that would not occur if the program did not exist. Total 
ownership costs are all the costs associated with a system 
known as "cradle to grave." The Defense Systems Management 
College (DSMC) describes a successful system acquisition 
program as one that places a capable and supportable system 
in the hands of a user when and where it is needed, and does 
so within the bounds of affordability (DSMC, 1996) . DoD 
Regulation 5000.2-R defines affordability as the degree to 
which the LCC of an acquisition program is in consonance 
with the long-range investment and force structure plans of 
the DoD or individual DoD Components. Affordability 
procedures establish the basis for fostering greater program 
stability through the assessment of program affordability 
and the determination of affordability constraints. LCC 
estimates (LCCE) form the basis for budget requests to 
Congress, therefore acquisition managers are faced with 
fiscal constraints that are based on the LCCE. 

DoD Regulation 5000.2-R states that the best time to 
reduce LCC is early in the acquisition process. Cost 
reductions are accomplished through cost/performance 
tradeoff analyses. In the past, acquisition managers would 
make cost/performance tradeoffs early in the acquisition 
process based on their current budget and because 
performance was the independent variable (performance was 
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the most important variable) (Higgins, 1997). They would 
not consider the long-term impacts to production, 
deployment, operational, support, and disposal costs of a 
system. They were focused on their current cost, schedule, 
and performance issues, which were mainly based on their 
current fiscal constraints. Additionally, those costs were 
not their concern. Their performance rating was not 
affected by future costs of operating and sustaining the 
weapon system that they were developing. They could "throw 
it over the wall" to the operational and sustainment 
commands, who had to accept the weapon system and budget 
accordingly. Defense budgets are shrinking or remaining 
constant, which has forced DoD to require acquisition 
managers to responsible for optimizing a weapon system's 
total ownership costs using CAIV and IPTs. 

5. Performance Specification 

A 1991 study conducted by the Center for Strategic 
International Studies (CSIS) concluded that military 
specifications resulted in higher prices for DoD purchases 
than for purchase of commercial alternatives that could 
satisfy the same requirements (DSMC, 1997). In the past, 
the use of performance specifications required a waiver. On 
29 June 1994, then Secretary of Defense William Perry 
reversed this policy by directing the use of performance 
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specifications, along with requiring a waiver from the MDA 
for the use of military specifications and military 
standards. DoD Regulation 5000.1 now states that in 
solicitations and contracts, standard management approaches 
or manufacturing processes are not required. It further 
states that performance specifications will be used in 
purchasing new systems, major modifications, and commercial 
and nondevelopmental items. 

DoD's focus is now on performance, rather than detailed 
designs, to better concentrate on satisfying the 
warfighters' needs. The use of performance-based 
specifications allows maximum trade space without 
compromising the KPPs (DoD, 1998). The performance 
specification states what is required, not how to accomplish 
it. This allows IPTs to develop innovative approaches to 
satisfy the warfighters' needs while satisfying CAIV and 
total ownership costs objectives. The use of performance 
specifications allows the implementation of dual-use 
technologies that will help share the cost, thereby lowering 
the cost of military systems. Dual-use technologies are 
technologies that can be used for both military and 
commercial applications. 
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6. Earned Value Management System 

The traditional "cost/schedule management" has been 
reengineered as "earned value management" (EVM), integrating 
cost, schedule, and performance aspects of acquisition 
programs. The cost/schedule management was reengineered to 
provide insight into the contractor's efforts and processes 
and to have acquisition managers take ownership of the 
program baseline. The purpose of an earned value management 
system (EVMS) is to identify cost and schedule variances in 
real time, to allow management of cost and schedule risk. 
These three variables, cost, schedule, and performance, are 
interrelated, thus planned and unplanned changes to any one 
variable will usually affect one or both of the other 
variables. The EVMS measures work accomplishment versus 
technical accomplishment. Acquisition managers, both 
Government and contractor, are evaluated according to cost, 
schedule, and performance. They need to understand the 
relationship between these variables so that they can manage 
the variables to reduce the potential for and severity of 
unplanned changes or program risk. Effective management 
control systems are essential for managing program risk. 

The management control systems must be valid, timely, and 
auditable to properly relate cost, schedule, and performance 
(DA, 1999). 
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Earned value (EV) is a method for measuring program 
performance. It compares the amount of work that was 
planned known as the Budgeted Cost of Worked Performed 
(BCWP), with what was actually accomplished known as Actual 
Cost of Worked Performed (ACWP), to determine if cost and 
schedule performance is as planned. A program baseline is 
established early in the program or contract and variances 
to this baseline are reported. Variance analysis is 
conducted, which provides IPTs with the information they 
need to make informed management decisions. The IPTs need 
to establish cost and schedule reporting requirements to 
identify what can and will be effectively used to manage the 
program. Too much information will increase the cost of 
maintaining and reporting of the EVMS, as well as reducing 
the effectiveness of the EVMS. 

7. Integrated Management Plan (IMP) and Integrated 
Management Schedule (IMS) 

DoD Regulation 5000.1 states that DoD will use a 
rigorous, event-oriented management process that emphasizes 
effective acquisition planning, improved and continuous 
communications with users, and prudent risk management by 
both the Government and industry. This means that the 
acquisition process is based on significant events and not 
arbitrary calendar dates. The Integrated Management Plan or 
Integrated Master Plan (IMP) is an event-driven plan that 
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docxzments the significant accomplishments necessary to 
complete the tasks defined in the statement of objectives 
(SOO) or the statement of work (SOW) and ties these 
accomplishments to a key program event. Each significant 
event has exit criteria to facilitate the assessment of 
successful completion. The IMP is oriented by product using 
the WBS niombering system and contains no calendar 
information (DA, 1999). 

The Integrated Management Schedule (IMS) or Integrated 
Master Schedule (IMS) is a detailed, time-dependent, task- 
oriented schedule of the effort required, to accomplish the 
program and its relationship to the events, accomplishments, 
and exit criteria identified in the IMP. The IMS is 
traceable to the IMP and WBS, and contains the predecessors 
and successors tasks and their dependencies. The IMP and 
IMS provide the Government insight into how the contractor 
will perform work (DA, 1999). 

8. Alpha Contracting 

Alpha Contracting is an innovative use of IPTs in the 
pre-award phase of sole-source, negotiated contracts. Alpha 
Contracting is a technique that uses a team approach to 
prepare, evaluate, and award proposals in substantially less 
time than the traditional approach. Alpha Contracting is a 
concurrent versus a serial process that shortens procurement 
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cycle-time and significantly reduces proposal preparation 
costs. The goal of Alpha Contracting is to acquire quality 
products for the warfighter in an expedited and efficient 
manner at a fair and reasonable price. The Alpha 
Contracting IPTs consist of the user, acquisition managers, 
and contracting officers from both the Government and 
contractor to include principal subcontractors, the Defense 
Contract Audit Agency, the Defense Contract Management 
Command (DCMC), and various support organizations. During 
Alpha Contracting, the contract and cost and technical 
detail are jointly developed to replace the solicitation and 
proposal with a "model contract." The IPTs adjusts the 
model contract to lower cost and risk. This process allows 
the Government to have greater program, insight to contract 
cost, schedule, performance, and risk. Additionally, this 
allows the contractor to fully understand what is required, 
eliminating non-value added requirements (DAD, Army- 
Acquisition Reform; Tools and Techniques Guidebook, March 
1999;. 

9. Single Process Initiative (SPI) 

In the past, DoD contractors have been inhibited from 
making major changes in many of their processes because 
military and standard specifications dictated how-to 
requirements. The Single Process Initiative (SPI) is an 
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expansion of Secretary of Defense Perry's directive to 
eliminate military and standard specifications and to the 
use performance specifications. The goal of SPI is to 
eliminate the multiple processes imposed by various existing 
DoD contracts into a single common commercial process, 
thereby saving money, obtaining a better system or product, 
and fostering a more competitive industry (Kaminski, 1996). 
SPI provides opportunities for contractors to reengineer and 
standardize processes on a facility-wide basis when it makes 
good business sense. This not only includes technical 
processes, but also business processes. SPI facilitates 
contractors to take ownership of their processes and 
encourages them to baseline and improve their processes by 
applying best practices. 

C. SUMMARY 

Acquisition reform is about saving the taxpayer money, 
reinventing Government, strengthening our military, and 
improving the economy. At the core of acquisition reform is 
reducing cycle-times and the use of insight versus 
oversight. DoD, the Administration, and Congress have been 
removing requirements that are uniquely imposed on defense 
contractors. This has allowed contractors to compete 
successfully in today's global marketplace, ensure DoD has 
access to the latest technology, and assist DoD in reducing 
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its acquisition costs. The way DoD procures systems is 
continuing to evolve as DoD attempts to provide the 
warfighter the best product, at the best dollar value, in 
the timeliest manner. There have been many acquisition 
reform successes and failures, but DoD is searching for new 
ways to more effectively implement and accelerate 
acquisition reform initiatives. How one prepares the WBS, 
may be one of those techniques. 
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III. OVERVIEW OF MIL-HDBK-881 "DEPARTMENT OF DEFENSE (DOD) 
HANDBOOK - WORK BREAKDOWN STRUCTURE (WBS)" 

A. INTRODUCTION 

DoD Regulation 5000.2-R requires a program WBS be 
established that provides a framework for program and 
technical planning, cost estimating, resource allocations, 
performance measurements, and status reporting, using the 
guidance in MIL-HDBK-881. It further requires that the WBS 
and associated WBS dictionary define the total system to be 
developed or produced; display the total system as a 
product-oriented family tree composed of hardware, software, 
services, data, and facilities; and relate the elements of 
work to each other and to the end product. It also requires 
that MIL-HDBK-881 be sited in solicitations and contracts 
"for guidance only" in extending the program WBS to develop 
the complete contract WBS (DoD, March 1998). This chapter 
reviews MIL-HDBK-881. 

B. ISSUANCE 

MIL-STD-881 was converted to MIL-HDBK-881 as a result 
of the performance specification acquisition reform 
initiative. There were no substantive changes in WBS 
definition (DoD, January 1998). MIL-HDBK-881 offers 
uniformity in definition and consistency of approach for 
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developing the top three levels of the WBS. MIL-HDBK-881 is 
for guidance only and cannot be cited as requirement. It 
was issued on 2 January 1998. 

C. PURPOSE 

MIL-HDBK-881 provides instructions on how to prepare, 
understand, and construct a program WBS in the context of 
planning and monitoring of DoD materiel programs. It 
provides guidance for developing and implementing a contract 
WBS. It discusses the role of the WBS in contract 
negotiation and award and in post-contract performance. 

It's appendices present generic definitions of WBSs for 
several DoD system categories. The primary purpose of MIL- 
HDBK-881 is to provide a consistent application of the WBS 
across DoD. MIL-HDBK-881 can be applied during any 
acquisition phase (Concept Exploration, Program Definition 
and Risk Reduction (PDRR), Engineering and Manufacturing 
Development (EMD), or production). 

D. WBS DEFINITION 

1. General 

The WBS is a tool used to organize acquisition 
development activities based on system and product 
decompositions. The WBS is a tool that allows PMs to break 
large tasks into smaller, understandable tasks. MIL-HDBK- 
881 states the WBS will be developed and maintained based on 


36 


the systems engineering efforts throughout its life-cycle. 
MIL-HDBK-881 defines the WBS as follows: 

• A product-oriented fcunily tree composed of hardware, 
software, services, data, and facilities. The family 
tree results from systems engineering efforts during 
the acquisition of a defense materiel item. 

• A WBS displays and defines the product, or products, to 
be developed and/or produced. It relates the elements 
of work to be accomplished to each other and to the end 
product. 

• A WBS can be expressed down to any level of interest. 
However the top three levels are as far as any program 
or contract need go unless the items identified are 
high-cost or high-risk. Then, and only then, is it 
important to take the work breakdown structure to a 
lower level of definition. 

MIL-HDBK-881 states several times that the WBS must be 
product-oriented, not an organization structure. It should 
represent identifiable work products whether they be 
equipment, data, or related service products. 

MIL-HDBK-881 appendices present definitions of WBSs for 

seven generic DoD system categories, which can be used as a 

starting point to construct a WBS for a specified program. 

The WBS for each of the seven categories is included in 

Appendix A through G of this document. MIL-HDBK-881 defines 

the following system categories: 

• aircraft system — applies to fixed or movable wing, 
rotary wing, or compound wing manned/unmanned air 
vehicles designed for powered or unpowered (glider) 
guided flight (Appendix A) 
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• electronic/automated software system -- applies to 

electronic, automated, or software system capability 
(Appendix B) 

• missile system — applies to a weapon in an 

operational environment which produces a destructive 
effect on selected targets (Appendix C) 

• ordnance system — applies to all munitions (nuclear, 
biological, chemical, psychological, and 
pyrotechnic) and the means of launching or firing 
them (Appendix D) 

• ship system — applies to naval weapons, or 
performing other naval tasks at sea (Appendix E) 

• space system — applies to developing, delivering, 

and maintaining mission payloads in specific orbit 
placement, operation, and recovery of manned and 
unmanned space systems (Appendix F) 

• surface vehicle system — applies to navigation over 

the surface (Appendix G) 

2. Elements 

It is difficult to find a definition of an element. An 
element of the WBS should represent identifiable work 
products whether they be equipment, data, or related service 
products. MIL-HDBK-881 states that each element of the WBS 
provides logical summary points for assessing technical 
accomplishments and for measuring the cost and schedule 
performance accomplished in attaining the specified 
technical objectives. The WBS has an end product part and 
an enabling product part (DSMC, October 1999). The end 
product part is what is delivered to the warfighter and is 
based on the physical structure developed from the 
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requirements or the product development. Figure 3.1 
presents an example of a program WBS product part. The 
enabling product part is the products and services 



Figure 3.1. Program WBS - The Product Part (Extracted from DSMC, Systems Engineering 

Fundamentals) 


required develop, produce, and support the end product. 
Figure 3.2 presents an example of a complete program WBS as 
defined in Appendix A for an aircraft system (DSMC, October 
1999) . 

MIL-HDBK-881 lists these common elements that are 
pertinent to all seven DoD system categories. They are: 

• integration, assembly, test, and checkout efforts 

• systems engineering and program management 

• training 

• data 

• system test and evaluation 

• peculiar support equipment 

• common support equipment 

• operational and site activation 

• industrial facilities 

• initial spares and repair parts 
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Appendix H further defines these common elements. 


Level 1 




Aircraft Systems WBS 
(MIL*HDBK-dd1) 


Level 2 
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Figure 3.2. Complete Program WBS for an Aircraft System (Extracted from DSMC, Systems 

Engineering Fundamentals) 


3. Level Identification 

The WBS is divided into levels of hierarchy as can be 
seen in Figure 3.1 and Figure 3.2. MIL-HDBK-881 defines the 
top three levels as: 

• Level 1 is the entire defense materiel item/ for 

example, an electronic system. An "electronic system" 
might be a command and control system, a radar system, 
a communications system, an information system, a 
sensor system, a navigation or guidance system, or an 
electronic warfare system. Level 1 is usually directly 
identified as a program or a sub-element of a program. 

• Level 2 elements are the major elements of the defense 
materiel item; for example, a fire control system or an 
automatic flight control system. These prime mission 
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products include all hardware and software elements, 
aggregations of system level services (like system test 
and evaluation, or systems engineering and program 
management), and data. 

• Level 3 elements are elements subordinate to level 2 
major elements. For example, a radar data processor, a 
signal processor, an antenna, a type of service (like 
development test and evaluation, contractor technical 
support, or training seirvices) , or a type of data (like 
technical publications) would be typical level 3 
elements for an electronic system. Lower levels follow 
the same process. 

E. PRPGRAN WBS AMD CONTRACT MBS 

MIL-HDBK-881 describes two types of WBSs, the program 
WBS and the contract WBS. The PM is responsible for 
preparing and maintaining the program WBS. It describes the 
program WBS as the structure that encompasses an entire 
program and provides a framework for specifying the 
objectives of the program. The program WBS consists of at 
least the three top levels as can be seen in Figure 3.2, and 
is used to develop and extend the contract WBS. The 
contract WBS includes all the elements of the program WBS 
that are the responsibility of the contractor. The contract 
WBS is used to organize and identify contractor tasks. 

Figure 3.3 presents only the product part of the contract 
WBS. A complete contract WBS would include the enabling 
products. The Fire Control element is at level 3 of the 
program WBS, but it is at level 1 of the contract WBS since 
that is the product the Government is procuring. The 
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contract WBS includes the applicable program WBS elements 
extended to the agreed contract reporting level and any 
discretionary extensions to lower levels based on high-cost 
or high-risk. The contract WBS forms the structure for the 
contractor's management control system. 



Figure 3.3. Contract WBS (Extracted from DSMC, Systems Engineering Fundamentals) 

Work is documented as resources are allocated and 
expended through the program WBS and contract WBS. MIL- 
HDBK-881 states that technical, schedule, and cost data are 
generated for reporting purposes. The WBS summarizes the 
data for successive levels of management and provides the 
appropriate information on the projected, actual, and 
current status of the elements for which they are 
responsible. This allows the PM, in cooperation with the 
contractor, to monitor program status so that they can 
identify and implement changes necessary to assure desired 
performance. 
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F. DEVELOPING A NBS 

MIL-HDBK-881 breaks this into two chapters, one for the 
program WBS and one for the contract WBS. The generic WBSs 
defined in Appendices A through G provide the basis for the 
program or contract WBSs. The WBS may use more than one of 
the categories or elements defined in the Appendices. MIL- 
HDBK-881 allows this "as long as the integrity of the level 
of placement is maintained." 

1. Developing the Program WBS 

MIL-HDBK-881 states that the program WBS should be 
developed early in the conceptual stages of the program. It 
evolves through iterative analysis of the program objective, 
functional design criteria, program scope, technical 
performance requirements, proposed methods of performance, 
and other technical documentation. The program WBS elements 
are selected based on the appropriate product parts of the 
system being developed along with the appropriate enabling 
product parts. These elements can consist of other elements 
from generic categories. The systems engineering efforts 
aid in defining the description of the system and its 
related levels throughout the life-cycle. The WBS will 
become more defined during each successive acquisition phase 
along with defining lower levels of the WBS reflecting the 
way business is planned and managed. MIL-HDBK-881 states 
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that the levels of the WBS are directly linked with the 
detailed configuration of the system. The program WBS can 
be both the program and contract WBS based on how it relates 
to the Government activity. For example, if a contract were 
awarded for the development of a complete system, then it 
would be both a program and contract WBS. 

MIL-HDBK-881 states that for each WBS element, the 
detailed technical objectives are defined and specified work 
tasks are assigned along with the resources, materials, and 
processes required to attain the objectives. The linkage 
between the specification, the WBS, the SOW, and the master 
and detailed schedules provides specific insights into the 
relationship between cost, schedule, and performance. This 
relationship allows all items to be tracked to the same WBS 
element. The levels of the program WBS should be related to 
these requirements and conform to its product-oriented 
family tree. 

2. Developing the Contract WBS 

The PM selects WBS elements from the program WBS that 
apply to the contract. This becomes the initial contract 
WBS. It along with the initial contract WBS dictionary 
(discussed later) is included in the Request for Proposal 
(RFP). MIL-HDBK-881 States that the RFP should instruct 
potential contractors to extend the selected contract WBS 
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elements to define the complete contract scope. MIL-HDBK- 
881 reiterates that the contract line items, configuration 
items, contract work statement tasks, contract 
specifications, and contractor responses will be relatable 
to the WBS to enhance its effectiveness in satisfying the 
objectives of the particular acquisition. Combining the 
program WBS with the contract WBS(s) will form a complete 
WBS of the program for use throughout the acquisition phase. 

The contract WBS provides the framework for the 
management control system. Contractors submit their 
extended contract WBS with their proposal. The contractor's 
expanded WBS must address all contract WBS elements in the 
RFP. MIL-HDBK-881 states that their proposed contract WBS 
should be based on the WBS in the RFP, although contractors 
may suggest changes needed to meet an essential requirement 
of the RFP or to enhance the effectiveness of the contract 
WBS in satisfying program objectives. It also states that 
contractors are expected to extend the contract WBS to the 
appropriate level - the level that satisfies the critical 
visibility requirements and does not overburden the 
management control system. MIL-HDBK-881 states that 
contractors should include lower breakdown levels where they 
identify risk associated with technical issues or resources. 
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and identify control plans whether or not the items are 

reported back to the Government. 

MIL-HDBK-881 states that WBS revisions may result due 

to further elements selected for the contract will become 

the basis for contractor extension during the contracted 

effort as both parties become more knowledgeable about the 

effort. MIL-HDBK-881 states the following note: 

Normally, once work is underway after 
contract award, changes to the work breakdown 
structure should not be made unless major 
rescoping of the program occurs. 

MIL-HDBK-881 states that the WBS should not influence 
or in any way affect the contractor's program organization. 
A contractor can be organized in any way, by function, 
process, or IPT, and effectively use a valid, product- 
oriented WBS. This is because at some level in an 
organization, as well as the WBS, a cost account is managed 
The WBS is visible regardless of the contractor's 
organization. 

3. WBS Dictionary 

The PM develops a WBS dictionary while developing the 
program WBS. MIL-HDBK-881 states the requirement for 
providing the WBS dictionary is placed in the Contract Data 
Requirements List (CDRL). The contractor while developing 
the contract WBS expands the WBS dictionary. The WBS 
dictionary lists and defines the WBS elements. The WBS 
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dictionary defines a common language that should be clearly 
understood by all stakeholders. It should eliminate any 
possible confusion. MIL-HDBK-881 states that the initial 
WBS dictionary should be based on the generic definitions in 
the handbook and made program-specific to define the 
products being acquired. The WBS dictionary describes each 
WBS element and the resources and the processes required to 
produce it. The WBS dictionary should be routinely revised 
throughout the program's life to incorporate changes to the 
program. Figure 3.4 is an example of a level 2 WBS element 
dictionary entry. 


Index Item No. 2 


WBS Level 2 

CONTRACT NUMBER 

F33657-72-C-0923 

WBS Element 

A10100 

WBSTItle 

AirVehide 

Contract 

Line Item: 

Date 

Revision No. 

Revision Auth 

Approved Chg 

0001,0001AA, 0001AB, 0001AC, 0001AD 

0001AE, 0001AF, 0001AG, 0001 AH 

Specification No. 

689E078780028 

SpecIflcationTItle: 

Prime Item Development 

Spedficaiton for AGM 86A AirVehide/ 
Airframe 


! 

ElementTask Description 

Technics! Content 

The Air Vehicle element task description refers to the effort 
required to develop, fabricate, integrate and test the 
airframe segment, portions of the Navigatin/Guidance 
element, and Airborne DevelopmentTest Equipment and 
Airborne Operational Test Equipmentand to the Integration 
assembly and check-out of these complete elements, 
togetherwith the Engine Segment, to produce the complete 

Air Vehicle. The lower*level elements included and 
summarized in the Air Vehicle element are: 

Airframe Segment (A11100}, Navigation/Guidance 

Segment (A32100), Airborne Development Test 

Equipment (A61100), and Airborne Operational Test 
Equipment (A61200) 

Cost Description 

MPC/PMC Work OrderyWork Auth 

A10100 Seelowerlevel 

WBS Elements 

Cost Content^ System Contractor 

The cost to be accumulated against this element includes 
a summarization of all costs required to plan, develop, 
fabricate, assemble, integrate and perform development 
testing, analysis and reporting for the air vehicle. It also 
includes all costs assodated with the required efforts in 
integrating, assembling and checking our GFP required to 
create this element 

Applicable SOW Paragraph 

3.6.2 


Figure 3.4. WBS Dictionary Level 2 Entry (Extracted from the DSMC, Systems Engineering 

Fundamentals) 
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4. Avoiding Pitfalls in Constructing a VJBS 

MIL-HDBK-881 states that a sound WBS clearly describes 
what the PM wants to acquire. It has a logical structure 
and is tailored to a particular materiel item. The WBS may 
tie the SOW, contract line item number (CLIN) structure, and 
the system description documents together. The WBS 
addresses the products required, not the functions or costs 
associated with those products. MIL-HDBK-881 lists the 
following elements that are to be excluded from the WBS: 

• Do not include elements which are not products. A 

signal processor, for example, is clearly a product, as 
are mock-ups and Computer Software Configuration Items 
(CSCIs). On the other hand, things like design 
engineering, requirements analysis, test engineering, 
aluminum stock, and direct costs, are not products. 
Design engineering, test engineering, and requirements 
analysis are all engineering functional efforts; 
alxominum is a material resource; and direct cost is an 
accounting classification. Thus none of these elements 
are appropriate WBS elements. 

• Program phases (e.g., design, development, production, 
and types of funds, or research, development, test and 
evaluation) are inappropriate as elements in a WBS. 

• Rework, retesting and refurbishing are not separate 
elements in a WBS. They should be treated as part of 
the appropriate WBS element affected. 

• Non-recurring and recurring classifications are not WBS 
elements. The reporting requirements of the Contractor 
Cost Data Reporting (CCDR) will segregate each element 
into its recurring and non-recurring parts. 

• Cost saving efforts such as total quality management 
initiatives, could cost, and warranty are not part of 

the WBS. These efforts should be included in the cost 
of the item they affect, not captured separately. 
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• Do not use the structure of the program office or the 
contractor's organization as the basis of a f9BS. 

• Do not treat costs for meetings, travel, computer 
support, etc. as separate WBS elements. They are to be 
included with the WBS elements with which they are 
associated. 

• Use actual system names and nomenclature. Generic 
terms are inappropriate in a WBS. The WBS elements 
should clearly indicate the character of the product to 
avoid semantic confusion. For example, if the Level 1 
system is Fire Control, then the Level 2 item (prime 
mission product) is Fire Control Radar. 

• Treat tooling as a functional cost, not a WBS element. 

Tooling (e.g., special test equipment, and factory 
support equipment like assembly tools, dies, jigs, 
fixtures, master forms, and handling equipment) should 
be included in the cost of the equipment being 
produced. If the tooling cannot be assigned to an 
identified subsystem or component, it should be 
included in the cost of integration, assembly, test, 
and checkout. 

• Include software costs in the cost of the equipment. 

For example, when a software development facility is 
created to support the development of software, the 
effort associated with this element is considered part 
of the CSCI it supports or, if more than one CSCI is 
involved, the software effort should be included under 
integration, assembly, test, and checkout. Software 
developed to reside on specific equipment must be 
identified as a subset of that equipment. 


MIL-HDBK-881 does not identify level 3 elements for the 
systems engineering and program management WBS elements. It 
also cautions that too much detail may limit the flexibility 
of the PM and the contractor. MIL-HDBK-881 states that 
system test and evaluation always separately identifies 
those tests performed in the development test and 
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evaluation, i.e., development test and evaluation, and those 
tests performed by the operational user, i.e., operational 
test and evaluation. 

MIL-HDBK-881 states that it is incorrect to summarize 
all software on a program or contract in a WBS. By 
separating software from the hardware they support, 
performance measurement and management control over each 
product is difficult to maintain. The true cost of each 
product is not readily available for decisions concerning 
that product. MIL-HDBK-881 states that rather than 
separately siimmarizing software, it is important to identify 
software with the hardware it supports. 

5. Integrated Cost, Schedule, and Technical 
Per£o 2 :iaance Meuiagement 

The prime use of the WBS is design and the tracking of 
work. MIL-HDBK-881 states that planning work by WBS 
elements serves as the basis for estimating and scheduling 
resource requirements known as work packages. A work 
package is prepared for each element at its lowest level in 
the WBS. The work package is a complete description for 
each task. It includes the what, how, when, by whom, and 
the budget for each task (Forsberg, Mooz, and Cotteirman, 

1996) . Cost accounts are created when the WBS element is 
matrixed against those organizations in the company 
responsible for the tasks as shown in Figure 3.5. The 
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organization structure depicted in Figure 3.5 could be an 
IPT organization as well. The WBS divides the product into 
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Figure 3.5. WBS Control Matrix (Extracted from DSMC, Systems Engineering Fundamentals) 


smaller increments so that management can ensure that all 
required products are identified in terms of cost, schedule, 
and performance goals. MIL-HDBK-881 states that virtually 
all aspects of the contractor's management control system: 
technical definition, budgets, estimates, schedules, work 
assignments, accounting, progress assessment, problem 
identification, and corrective actions, come together at the 
cost account level. Assigning performance budgets to work 
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segments and identifying responsible units, produces a time- 
phased plan against which actual performance can be 
measured. An IMP and IMS can now be created. As discussed 
in Chapter II, the IMP is the specific tool used to track 
and measure successful task completion and is event-based. 

G. SUMMARY 

DoD Regulation 5000.2 R requires a program WBS be 
established using the guidance in MIL-HDBK-881. MIL-STD-881 
was converted to MIL-HDBK-881 as a result of the performance 
specification acquisition reform initiative. MIL-HDBK-881 
provides instructions on how to prepare, understand, and 
construct both a program WBS and a contract WBS. MIL-HDBK- 
881 provides seven generic DoD system categories. The WBS 
format in MIL-HDBK-881 is to be used as a starting point for 
constructing and tailoring a WBS. The WBS is a tool used to 
organize and coordinate work to be completed on a program. 
The Government PM prepares the program WBS and the initial 
contract WBS. The contractor develops lower levels of the 
contract WBS based on the work required by the contract. 

Work packages and cost accounts are established along with 
an IMP and IMS, which become the baseline against which 
performance is measured. 
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IV. ANALYSIS OF THE WORK BREAKDOWN STRUCTURE (WBS) 


A. INTRODUCTION 

The previous chapters presented information on 
acquisition reform initiatives and MIL-HDBK-881's guidance 
concerning how to construct a WBS. This chapter analyzes 
how a WBS that is constructed in accordance with MIL-HDBK- 
881 facilitates or impedes the acquisition reform 
initiatives presented in Chapter II. Many of the assertions 
and conclusions in this thesis are based on experiences and 
discussions with Government and contractor personnel during 
my career. This analysis is also based on poorly-written 
WBSs prepared by the researcher who as a result, suffered 
the consequences of attempting to manage with meaningless 
data. Before conducting this analysis, a general discussion 
concerning the various perspectives of WBS stakeholders, the 
systems engineering process (SEP), and considerations when 
preparing the WBS is presented. Then based on this 
analysis, an alternative WBS is developed and analyzed. 

B. GENERAL 

The major stakeholders in constructing the WBS are the 
Government PM, Government systems engineer, contractor PM, 
and the contractor systems engineer. How a WBS is 
constructed depends on each of their perspectives. As 


53 



stated in Chapter I, the challenge in developing a WBS is to 
balance the program definition aspects against its data- 
generating aspects. The PMs tend to focus more on the data- 
generating aspects of the WBS, whereas the systems engineers 
focus more on the program definition aspects of the WBS. 

The Government and contractor PMs require the WBS be 
constructed so that it provides insight to cost, schedule, 
performance, and risk. They require this data to 
effectively manage the program. The Government PM is trying 
to ensure that the Government is obtaining the best value 
for their dollar spent. Additionally, the Government PM is 
attempting to ensure the program will be completed on budget 
and on schedule and provide the desired performance required 
by the warfighter. In contrast, the contractor PM is 
attempting to ensure they have insight so that the company 
obtains a profit, as well as ensuring the program will be 
completed below budget and ahead of schedule and provide the 
desired performance required by the warfighter. The 
Government and contractor systems engineers require the WBS 
be constructed so that they can clearly define the products 
and tasks to be accomplished, and execute the program. 

Their approaches are rarely the same since there are many 
possible solutions and approaches to satisfy a requirement. 
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In today's acquisition environment, one uses an IPT to 
construct a WBS. Additionally, the WBS may be negotiated 
during the solicitation process to ensure that both 
Government and contractor perspectives are being satisfied. 
Throughout the rest of this analysis, I will attempt to 
balance the various perspectives. 

C. SYSTEMS ENGINEERING PROCESS OVERVIEW 

The systems engineering process (SEP) supports 
acquisition decision-making. It is the basic means for 
planning and assessing system development. Systems 
Engineering (SE) is an approach that encompasses the entire 
technical effort to develop, manufacture, verify, deploy, 
operate, support, dispose of, and train warfighters on the 
system products and processes. SE is the balancing of 
people, products, and process solutions that satisfy 
customer (warfighter) needs. SE attempts to answer the 
question, "How do you create a product that a customer 
needs, will be able to use, at the price they are willing to 
pay, and ensure that no safety hazards exist?" SE involves 
the discovery, understanding, focus, invention, action, 
feedback, and feed-forward (sharing) of knowledge. SE poses 
questions early and continuously in the acquisition process 
to prevent disasters, increased costs, schedule slippage, 
and decreased performance. The DSMC's Systems Engineering 
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Fundamentals states that SE is an interdisciplinary 
engineering management process to evolve and verify an 
integrated, life-cycle-balanced set of system solutions that 
satisfy customer needs (DSMC, October 1999). 

SE defines what is to be accomplished. SE does not 
define how to do what is to be done. Determining how to do 
what is to be done is a design engineering responsibility. 

SE develops a description of system parameters. These 
system parameters are documented in baseline specifications. 
SE is responsible for conducting tradeoffs to develop the 
system parameters. The SEP progressively decomposes or 
allocates the system requirements to the lowest level of 
detail (Forsberg, Mooz, and Cotterman, 1996). 

DoD Regulation 5000.2-R requires PMs to ensure that a SEP is 
used to translate operational needs and/or rec[uirements into 
a system solution that includes the design, manufacturing, 
test and evaluation, and support processes and products. 

The SEP establishes the proper balance between performance, 
risk, cost, and schedule, employing a top-down iterative 
process of requirements analysis, functional analysis and 
allocation, design synthesis and verification, and system 
analysis and control, as shown in Figure 4.1. Appendix I is 
extracted from Chapter 3 of DSMC's Systems Engineering 
Fundamentals. It explains the SEP depicted by Figure 4.1. 
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Figure 4.1. The Systems Engineering Process (Extracted from DSMC, Systems Engineering 

Fundamentals) 


DoD Regulation 5000.2-R recjuires the following SE 
activities depicted in Figure 4.1 to be performed: 

1. Requirements Analysis. Throughout the acquisition 
process the program office shall work with the user to 
establish and refine operational and design 
requirements that result in the proper balance between 
performance and cost within affordability constraints. 
Requirements analysis shall be conducted iteratively 
with functional analysis/allocation to develop and 
refine system level functional and performance 
requirements, external interfaces and provide 
traceability among user requirements and design 
requirements. 

2. Functional Analysis/Allocation. Functional 
analysis/allocation shall be performed iteratively to 
define successively lower level functional and 
performance requirements, including functional 
interfaces and architecture. Functional and 
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performance requirements shall be traceable to higher 
level requirements. System requirements shall be 
allocated and defined in sufficient detail to provide 
design and verification criteria to support the 
integrated system design. 

3. Design Synthesis and Verification. Design synthesis 
and verification activities shall translate functional 
and performance requirements into design solutions to 
include: alternative people, product and process 
concepts and solutions, and internal and external 
interfaces. These design solutions shall be in 
sufficient detail to verify requirements have been met. 
The verification of the design shall include a cost- 
effective combination of design analysis, design 
modeling and simulation, and demonstration and testing. 
The verification process shall address the design 
tools, products, and processes. 

4. System Analysis and Control. System analysis and 
control activities shall be established to serve as a 
basis for evaluating and selecting alternatives, 
measuring progress, and documenting design decisions. 
This shall include: 

• The conduct of trade-off studies among requirements 
(operational, functional, and performance), design 
alternatives and their related manufacturing, 
testing and support processes, program schedule, and 
life-cycle cost at the appropriate level of detail 
to support decision-making and lead to a proper 
balance between performance and cost. 

• The establishment of a risk management process to be 
applied throughout the design process. The risk 
management effort shall address the identification 
and evaluation of potential sources of technical 
risks based on the technology being used and its 
related design, manufacturing capabilities, 
potential industry sources, test and support 
processes, risk mitigation efforts, and risk 
assessment and analysis. Technology transition 
planning and criteria shall be established as part 
of the overall risk management effort. 

• A configuration management process to control the 
system products, processes, and related 
documentation. The configuration management effort 
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includes identifying, dociimenting, and verifying the 
functional and physical characteristics of an item; 
recording the configuration of an item; and 
controlling changes to an item and its 
documentation. It shall provide a complete audit 
trail of decisions and design modifications. 

• An integrated data management system to capture and 
control the technical baseline (configuration 
documentation, technical data, and technical 
manuals); provide data correlation and traceability 
among requirements, designs, decisions, rationale, 
and other related.program planning, and reporting, 
support configuration procedures, and serve as a 
ready reference for the systems engineering effort. 
PMs shall use existing information systems and data 
formats rather than DoD-unique systems and formats, 
provided they can readily meet the program's 
information requirements and do not pose 
compatibility issues with operational DoD 
information systems and data. 

• The establishment of performance metrics to provide 
measures of how well the technical development and 
design are evolving relative to what was planned and 
relative to meeting system requirements in terms of 
performance, risk mitigation, producibility, cost, 
and schedule. Performance metrics must be traceable 
to performance parameters identified by the 
operational user. 

• The establishment of interface controls to ensure 
all internal and external interface requirement 
changes are properly recorded and communicated to 
all affected configuration items. 

• A structured review process to demonstrate and 
confirm completion of required accomplishments and 
their exit criteria as defined in program planning. 
Reviews necessary to demonstrate, confirm, and 
coordinate progress shall be incorporated into 
overall program planning. 

In today's acquisition environment, IPTs conduct the 
SEP. During each of the SEP activities (Requirements 
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Analysis, Functional Analysis/Allocation, and Synthesis), 
IPTs will conduct System Analysis and Control activities to 
obtain knowledge from which to base a decision. During 
System Analysis and Control, IPTs attempt to solve unknowns. 
This is an iterative process, along with the requirements 
loop, design loop, and verification loop, each occurring 
several times during an acquisition phase. IPTs attempt to 
reduce this process cycle-time each time it is repeated. No 
decisions are made during System Analysis and Control 
activities. IPTs make decisions only during Requirements 
Analysis, Functional Analysis/Allocation, and Synthesis 
activities. 

During System Analysis and Control, IPTs use modeling, 
simulation, experimentation, and tests to obtain the 
necessary knowledge to make a decision. Depending on the 
acquisition phase, thirty-percent, fifty-percent, seventy- 
percent, ninety-percent, or full-scale systems will be used. 
Also, these systems may be referred to as prototype, 
preliminary, detailed, low-rate production, or production 
systems. Sub-scale models/systems usually cost less, 
require less time to fabricate, and have lower risk. To 
reduce risk from test to test, developers attempt to modify 
as few components as possible. This process allows them to 
quickly determine the cause of a failure, if it occurs. 
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This process also allows for reduction of the design, 
fabricate, test, analyze, and fix cycle-time. 

The SEP depicted in Figure 4.1 is conducted throughout 
the DoD acquisition phases as shown in Figure 4.2. The SEP 
produces configuration baselines as depicted in Figure 4.2. 
The functional baseline is the initial configuration 
baseline, which becomes the System Specification. As 
alternative solutions are developed and more knowledge is 
gained during SEP activities, the functional requirements 
are allocated down forming the allocated baselines, which 
become the Preliminary Design Specifications. Again as 
alternative solutions are demonstrated and more knowledge is 
gained during later SEP activities, the allocated baselines 
become product baselines, which become detailed item, 
process, and material specifications (DSMC, October 1999). 

At the end on each SEP cycle, a technical review is 
conducted to ensure the' phase objectives have been achieved. 
DoD is attempting to reduce this SEP cycle-time to reduce 
costs and field equipment rapidly. These technical reviews 
are: Alternative Systems Review (ASR), Systems Requirements 
Review (SRR), System Functional Review (SFR), Preliminary 
Design Review (PDR), Critical Design Review (CDR), 

Functional Configuration Audit (FCA)/System Verification 
Review (SVR), Physical Configuration Audit (PCA), Test 
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Figure 4.2. Systems Engineering and the Acquisition Life-cycle (Extracted from DSMC Systems 

Engineering Fundamentals) 
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Readiness Review (TRR), and Production Readiness Review 
(PRR). These technical reviews are depicted in Figure 4.2 
(DSMC, October 1999). These technical reviews should be 
event-driven, not calendar-driven. Normally, a test, 
examination, or demonstration is conducted during the 
verification loop. This event signals that adequate 
knowledge is known, the solution satisfies or has the 
potential to satisfy the requirements (depending on the 
acquisition phase), and that the program is ready to proceed 
through the next phase and repeat the SEP. 

SE is about doing the right thing right the first time 
(Forsberg, Moot, and Cotterman, 1996). IPTs are essential 
during the SEP to accomplish this. For example, changing 
paper early in the acquisition process is easier than 
changing hardware later in the acquisition process. 
Similarly, modifying a sub-scale system is easier than 
changing a full-scale system. The DSMC's Systems 
Engineering Fundamentals states that the SEP management is a 
critical support process for DoD acquisition. If the SEP 
management is successful, then the program will likely be 
successful. If the SEP management effort fails, then the 
program acquisition effort will also fail. 
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D. CONSIDERATIONS WHEN STRUCTURING A WBS 

The WBS provides a consistent and visible framework for 
defense materiel items, as well as the basis for 
communication throughout the acquisition process. The WBS 
unifies the planning, scheduling, cost estimating, 
budgeting, contracting, configuration management, and 
performance reporting disciplines. The WBS will take a 
large, complex, unmanageable program and break it into 
small, easily-understandable and manageable modules. These 
smaller modules are then linked to define a complete 
program. 

DoD acquisition officials and PMs want to have 
successful programs. They require tools that will allow 
them to provide the warfighter with an affordable, 
supportable, and operationally-effective and suitable system 
when it is needed. They want to know what they are doing, 
how are they going to do it, and when they are planning to 
do it. They want to ensure proper planning of all required 
tasks to successfully meet the objectives of the acquisition 
phase. They want to know that best practices are being 
logically employed to make their program successful. 
Additionally, they want to know what are the high-risk and 
high-cost areas that will require their attention. The WBS 
is the framework to allow PMs to quickly determine what they 
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are doing, how are they going to do it, and when they are 
planning to do it. 

The WBS is used to develop schedules and cost 
estimates. When cost and schedule estimates are developed 
early in the life a program, there is uncertainty or risk, 
usually high-risk, associated with the estimates. One tends 
to lose sight that the cost and schedule estimates are the 
IPTs best point estimate chosen from a range of possible 
outcomes. IPTs are used to attempt to quantify the degree 
of uncertainty. A Monte Carlo Simulation tool is also 
useful when attempting to quantify and add structure to cost 
estimating. A Monte Carlo Simulation is a system that uses 
random numbers to measure the effects of uncertainty in a 
spreadsheet model (Decisioneering, Inc., 1996). With a 
Monte Carlo Simulation tool like Crystal Ball, an IPT can 
describe a range of possible values for each uncertainty. 

The simulation produces a forecasted range of all possible 
outcomes along with the likelihood of achieving each 
outcome. This type of model moves beyond what-if analysis 
by providing a statistical picture of the range of 
possibilities inherent in the assxomptions (Decisioneering, 
Inc., 1996). Any IPT member can view the assumptions for 
each spreadsheet entry. These assumptions can be modified 
by the IPT as they progress through the acquisition phase. 
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As more knowledge is gained, the IPT can refine their 
assiamptions. This should be accomplished before each 
technical review depicted in Figure 4.2. The use of a Monte 
Carlo Simulation tool should result in more accurate and 
realistic estimates, along with a method to quantify and add 
structure to risk management. 

E. BASELINE NBS 

To conduct this analysis to determine the effectiveness 
of a WBS constructed in accordance with MIL-HDBK-881 in 
implementing acquisition reform initiatives, a baseline WBS 
is required. In Chapter III, I have used a WBS for an 
aircraft system presented in MIL-HDBK-881's Appendix A. 

This analysis will continue to use the aircraft WBS shown in 
Figure 4.3 as the baseline WBS. 

F. ANALYSIS OF BASELINE WBS EFFECTIVENESS IN IMPLEMENTING 

ACQUISITION REFORM INITIATIVES 

1. Streeunline Acquisition/Adopt ion of Ccnnmercial 
Practices 

DoD Regulation 5000.2-R requires PMs to use MIL-HDBK- 
881 to construct WBSs, even though PMs cannot require 
contractors to use MIL-HDBK-881. MIL-HDBK-881 presents 
guidelines, not requirements, for preparing WBSs. MIL-HDBK- 
881 's appendices provide a WBS for seven DoD system 
categories. The baseline aircraft system WBS along with 
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Figure 4.3. Baseline WBS (Extracted from DSMC, Systems Engineering Fundamentals) 


MIL-HDBK-881 allows implementation of streamlined 
acquisition and adoption of commercial practices. It is 
very difficult to determine the effectiveness of the 
implementation. Does this baseline WBS allow insight versus 
oversight and help reduce cycle-time? 

A WBS has an end product part and an enabling product 
part (DSMC, October 1999). The end product part of the 
baseline WBS is on the left side or the vertical part of the 
WBS in Figure 4.3. The enabling product part is the 
horizontal part of the WBS in Figure 4.3. So, the end 
product part has one level 2 element and several level 3 
elements, whereas the enabling product part has several 


67 















level 2 elements and a few level 3 elements. Where is the 


greater risk, the end product part or the enabling product 
part? The enabling product parts are, or should be, 
allocated to the end product parts during the SEP. This 
assertion is based on experience and the following example. 
To illustrate, level 2 WBS element. Data, is divided down 
into Technical Publications, Engineering Data, Management 
Data, Support Data, and Data Depository elements. Each of 
the end product parts at level 3 will contain each of these 
elements. The Airframe will have Technical Publications, 
Engineering Data, Management Data, Support Data, and Data 
Depository, as well as Propulsion. Technical Publications 
(TPs) are not a difficult task and could be considered a 
work package. However, if the TPs are not available when 
needed, a program will suffer. So a PM needs to ensure that 
TPs are scheduled and then empower the IPT members to ensure 
the task is completed. If the allocation of the enabling 
product parts to the end product parts occurs, then there is 
no need for the enabling product part of the WBS to exist at 
level 2. They would exist only at level 4, or lower, for 
each of the end product parts. Thus all risk should be 
allocated to the end product parts. 

Contractors report down to level 3 unless otherwise 
directed by the contract. The baseline WBS has only one 
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level 2 end product element and several level 3 end product 
elements. The PM will not have adequate insight into these 
higher risk end product elements. If DoD's objective is to 
increase insight, especially into those high-risk and high- 
cost elements, then the end product elements should be at 
level 2 of the WBS, not level 3. This will require 
contractors to report data at a higher level and in more 
detail, which will allow PMs to have greater insight 
(visibility) and lead to early identification of problem 
areas. 

MIL-HDBK-881 encourages lower level reporting where 
high technical risk or high-cost exists. This is contrary 
to normal business practice. If a PM were concerned with a 
specific issue, he would elevate it to a higher level, 
requiring it to be reported frequently and in more detail. 
Additionally, one tends to focus on levels 2 or 3 of the 
contract WBS unless there is a variance at those levels. 
This assertion again is based on my experience and 
discussions with Government and contractor acquisition 
managers. There are so many niombers, that you attempt to 
reduce them in order to try and understand them. This 
higher level summarization may mask lower level element 
variances. For example. Figure 3.5 decomposes the baseline 
WBS to level 5. The Receiver Group element is at level 5 
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and may contain software, which is normally high-risk in a 
program. The contractor reports data to level 5. If one is 
reviewing the higher WBS levels (2 and 3), a variance may 
not exist because the level 3 elements. Airframe or 
Propulsion, or level 5 elements. Antenna or Xmtr Group, may 
have a positive variance. This positive variance may offset 
the negative variance of the Radar or Receiver Group 
elements. Therefore, the PM would not have early insight to 
the software problem. Thus the PM would not be able to 
execute corrective actions to prevent negative cost or 
schedule impacts. At the higher level WBS, the PM would 
have early insight and be able to implement corrective 
actions to mitigate negative program impacts. 

The next part of the question, does the baseline WBS 
help to reduce cycle-time, is more difficult to address. 
During the SEP, tradeoffs are performed by IPTs. The end 
product IPTs will conduct tradeoffs that will impact the 
enabling product part and vice versa. With the enabling 
product part being separate from the end product part, the 
potential exists for no communication or miscoinmunication to 
occur. Additionally, the potential for the tradeoff 
decision to negatively impact the enabling product part or 
vice versa also exists. If either of the above occurs, then 
the cycle-time is not shortened because the tradeoff process 
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will have to be repeated or the program will experience a 
higher cost. Both results are unacceptable. Thus there is 
a potential of not reducing cycle-time when utilizing the 
baseline WBS. 

Based upon the definitions in Appendix H of MIL-HDBK- 
881 (Appendix H of this document), how IPTs are established 
and function, and my experience of working in an IPPD 
environment, I assert that the SE/Program Management element 
of the enabling product part should be separated into two 
level 2 elements, one entitled Program Management and the 
other entitled Systems Engineering Integration. Appendix H 
contains several sub-element descriptions into which the PM 
should have insight. The baseline WBS would have these sub¬ 
elements at level 4 or lower. Again, the PM would not have 
adequate insight into the contractor's activities to 
identify problem areas early enough to prevent cost and 
schedule impacts. Level 1 IPTs are normally a program 
management IPT and a system IPT (DSMC, October 1999 and 
Office of the USD(A&T), 1998). Based on my experience, the 
PM IPT establishes and maintains the top-level program plan 
and acts as program integrator of the lower level IPTs, with 
the authority to reallocate cost and schedule requirements 
between IPTs. Based on my experience, the Systems 
Engineering Integration Product Team (SEIPT) is responsible 
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for integration, allocation, and verification of technical 
requirements. Additionally, based on my experience and how 
IPTs operate, the Program Management element should have a 
sub-element entitled Business Management. Based on my 
experience, PMs are extremely busy and thus cannot attend 
each lower-level IPT meeting in order to be able to stay 
abreast of all the detailed activities. This Business 
Management sub-element encompasses the planning and 
management of all business areas of the program including: 
contracts, subcontracts, program control, finance, capital 
equipment, scheduling, data management. Government property, 
and purchasing and pricing (Tracer, 1998). A member from 
both the SEIPT and Business Management IPT are also members 
of the lower-level IPTs. These members serve as the "eyes 
and ears" of the entire SEIPT and Business Management IPT. 
They keep the various plans and documents updated to provide 
consistent and consolidated documents and plans to the 
lower-level IPTs, the PM IPT, and the Government. This' 
allows the PM to have a clearer picture of the contractor's 
activities and facilitate adoption of commercial practices. 

As stated earlier, the Systems Engineering sub-element 
should be titled Systems Engineering and Integration. 

Systems Engineering is mainly focused on integrating the 
subsystems or components. MIL-HDBK-881 states that WBS 
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elements should clearly indicate the character of the 
product to avoid semantic confusion, therefore the 
recommended name change to Systems Engineering Integration. 
This name better reflects and emphasizes the tasks to be 
completed. The level 3 elements under this level 2 element 
should reflect the work that is actually being planned or 
accomplished in the SEP. Those elements would be 
requirements management, technical management, support 
engineering integration. Integrated Logistics Support (ILS), 
reliability and maintainability. Human System Integration 
(HSI), manufacturing, and requirements verification. Based 
on my experience and lessons learned from NPS courses. 
Manufacturing would have two level 4 elements entitled: 
producibility program and quality assurance. ILS will be 
discussed later. These elements provide a clear picture of 
the work to be accomplished for the system being developed. 
This element and its sub-elements could also be part of each 
end product part. 

2. Integrated Product atnd Process Development 
(IPPD)/Integrated Product Team (IPT) 

In today's acquisition environment, IPTs are used to 
focus on products and processes. IPTs are formed using the 
WBS as depicted in Figure 2.2 (DSMC, October 1999). The end 
product part of the baseline WBS allows implementation of 
IPTs, as well as the enabling part of the baseline WBS. How 
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effectively are the IPTs structured by the baseline WBS and 
does this IPT structure allow the IPPD process to be 
effectively implemented? Another way to ask this question 
is, does this baseline WBS allow functional stovepipes? The 
enabling product part does allow the potential for test and 
evaluation, HIS, and ILS stovepipes. The enabling product 
part consists of these three functional areas. If the 
enabling product parts are not allocated to the end product 
parts, then a complete multi-disciplinary team may not 
exist. Additionally, if an IPT is not allocated all life- 
cycle requirements, then the IPT is conducting tradeoffs 
that will impact other IPTs. As discussed above in 
Paragraph 1, the potential exists for repeating the tradeoff 
process. 

For the end product IPTs to effectively function as a 
small program and use IPPD techniques, the enabling product 
part needs to be allocated to the end product or vice versa. 
For example, the enabling product part. Common Support 
Equipment, is broken down into Test and Measurement 
Equipment and Support and Handling Ecjuipment. The end 
product part. Propulsion, may require both Common Support 
Equipment elements. During the SEP, tradeoffs are conducted 
by the Propulsion IPT that will affect the Common Support 
Equipment IPT or vice versa. The discrepancies will need to 
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be resolved by the SEIPT, which may require the tradeoff 
analysis to be repeated by both IPTs, (Based on my 
experience, if an allocated requirement is breached by any 
lower level IPT, it is raised to the SEIPT to be resolved.) 
Thus, this baseline WBS does not effectively implement IPPD 
and IPTs. 

Before continuing, the baseline WBS end product parts 
require analysis. Do those elements breach any of the 
guidelines in MIL-HDBK-881 and are they actually products? 

In Chapter III under "Avoiding Pitfalls in Constructing a 
WBS," MIL-HDBK-881 states, "Include software costs in the 
cost of the equipment." The Baseline WBS lists two elements 
entitled Application Software and System Software that are 
in direct violation of MIL-HDBK-881. Also, many of these 
elements are requirements that should be allocated to true 
end products. Those true end products are Airframe, 
Propulsion, and what I will refer to as the Mission 
Equipment Package (MEP). This was determined based on 
conversations with US Marine Corps Major Eric Chase and US 
Army Captain Jason Galindo, both helicopter pilots attending 
NPS. As stated earlier, these end products should be at 
level 2 of the WBS since they are high-cost and probably 
high-risk. The MEP could have a sub-product entitled 
Cockpit. If the Cockpit were a high-risk or high-cost sub- 
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component, I would raise it to level 2 for the reasons 
indicated above. 

3. Cost As An Independent VarieQ>le (CAIV) 

The baseline WBS allows implementation of CAIV. How 
effectively does the baseline WBS implement CAIV? It 
depends on how well one can establish a cost for each 
element. As discussed above, the potential exists for the 
end product parts to affect the enabling product parts. 

Thus cost could be affected. An effective manager may be 
able to eliminate any affects, but it will require 
continuous monitoring. Based on my actual experience in 
implementing CAIV, it was next to impossible to accomplish 
utilizing the baseline WBS. If a test failed and had to be 
repeated, but was not planned, then what else was not going 
to be accomplished in order to fund this additional effort? 
What risks are the various elements absorbing? How does 
this track to the program objectives and exit criteria? The 
costs were spread across several elements and controlled by 
several IPTs. The coordination required to resolve this 
issue was very complex, requiring several man-hours of 
effort, which eventually resulted in the WBS and EVMS not 
being used to manage the program. 

To resolve this issue, the PM IPT looked at the program 
objectives for the PDRR acquisition phase and the exit 
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criteria established by the MDA to enter the EMD acquisition 
phase. Those objectives were then allocated to the SEIPT, 
along with the questions, "What needs to be done, how is it 
going to be done, and when will it be done?" The SEIPT then 
allocated these objectives to the appropriate level 2 
Product IPTs. The Product IPTs, along with active 
involvement of the SEIPT, determined the phases or smaller 
projects required to meet the objectives. The IPTs divided 
the remaining work into Flight Test 2 through Flight Test 6. 
Each Flight Test was a small program. The PM IPT was able 
to track all resources required to accomplish the objectives 
of each Flight Test. The SEIPT was able to allocate all 
requirements to each Product IPT for each Flight Test. This 
process assisted in being better able to identify and 
monitor the high-risk areas, along with improved 
implementation of CAIV. 

4. Total Ownership Costs 

DoD Regulation 5000.1 requires programs be managed to 
optimize total system performance and minimize the cost of 
ownership. Does the baseline WBS allow this? No, because 
the end product parts are not allocated to the enabling 
product parts and most of the end product parts are not end 
products. The end product IPTs are performing tradeoffs 
during the SEP, but they are not responsible for total cost 
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of ownership. The end product IPTs are conducting tradeoffs 
that will affect test and evaluation, training, data, 
peculiar and common support equipment, operational/site 
activation, industrial facilities, and initial spare and 
repair parts, all of which are not allocated to them. The 
outcome of these tradeoffs could increase or decrease unit 
cost of the end product, but decrease or increase the cost 
of training. 

This baseline WBS does not effectively integrate 
logistics. MIL-HDBK-881 states that the acquisition 
logistics element should be accommodated as indicated in the 
upper levels of the WBS. This technique creates the 
potential for a logistics stovepipe and does not allow 
effective tradeoffs. ILS needs to be an element of the 
SEIPT and further allocated to each end product. The 
logistics engineer/manager must be actively involved during 
all acquisition phases in both the SEIPT and each end 
product IPT in order to influence the design to reduce 
operating and maintaining costs. This will also allow the 
potential for design influence to reduce cost of training, 
data, peculiar and common support equipment, 
operational/site activation, industrial facilities, and 
initial spare and repair parts. As with the discussion on 
TPs, these elements or work packages are not difficult to 
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accomplish. The concern is, if they are not accomplished on 
time, it will adversely impact the program. PMs need to 
ensure the sub-elements or work packages are planned and 
then empower the IPTs to accomplish them. 

Based on my experience, PMs need to ensure that IPTs 
are using total ownership costs or life-cycle cost in their 
tradeoffs. There are many different cost terms and it is 
easy to become confused and use the wrong cost. Other cost 
terms include: development cost, flyaway cost, weapon system 
cost, procurement cost, program acquisition cost, and 
operating and support costs (DSMC, July 1999). A contractor 
may have a tendency to use current acquisition costs for 
that phase of development, because they control that cost 
data. 

5. Performance Specification 

The baseline WBS allows the use of performance 
specifications, but for which WBS elements do you prepare a 
performance specification? For example, how do you write a 
performance specification for Survivability? A 
Survivability performance requirement for the Airframe 
Performance Specification is relatively easier to prepare 
and verify than to prepare and verify a performance 
specification for survivability. Based on my experience, 
the potential exists for this process of preparing 
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performance specifications to be very complex, along with 
having the potential for a requirement to not being 
allocated, or of being allocated to the wrong end product. 
The enabling product parts must be allocated to the end 
product parts to effectively document the performance 
specifications for each end product part. Also, the end 
product parts should be products, not requirements. 

6. Earned Value Memag^ent System (EVMS) 

The baseline WBS allows implementation of the EVMS, 
although it does not allow adequate insight into the high- 
risk areas of the end product parts. The EVMS requires 
contractors to report down to level 3 of the contract WBS 
unless an element has high technical risk or high-cost. In 
this case, the contractor reports down to the lower levels. 
Also, if a variance exists, then the contractor must report 
to the lowest level to explain the variance and to identify 
the corrective action. As discussed earlier, the end 
product parts are higher risk than the enabling product 
parts and a variance may not exist at the baseline level 3 
elements because positive variances may cancel negative 
variances at level 4. The probability of a variance 
occurring with the enabling product parts is very low. 

Thus, the EVMS is not allowing adequate insight into 
potential high-risk areas. 
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The WBS is the framework for the EVMS to allow PMs to 


quickly determine what they are doing, how are they going to 
do it, and when they are planning to do it. The baseline 
WBS does not effectively provide the framework to allow PMs 
to quickly determine what they are doing, how are they going 
to do it, and when they are planning to do it. As stated 
earlier, the WBS should reflect the key products and 
processes that are of high-risk and high-cost. The EVMS 
should reflect IPPD and SEP activities. Is the contractor 
or the IPTs applying the SEP and best practices to develop 
the end products? It will be difficult to assess since the 
low-cost, low-risk, high-cost, and high-risk elements are 
all entangled. The EVMS must provide PMs with the right 
information and at the right time. The EVMS must highlight 
potential problem areas that allow the PM to implement 
corrective actions to prevent negative program impacts. 

MIL-HDBK-881 does not allow low-risk elements to be 
placed at a lower WBS level. MIL-HDBK-881 cautions that the 
integrity of the level of placement be maintained and not to 
overburden the contractor's management control system. 

Based on my experience, the baseline WBS is having the 
contractor report EVMS data that is of no use to the 
contractor or the Government. 
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7. Integrated Management Plan (IMP) etnd Integrated 
Management Schedule (IMS) 

The baseline WBS allows implementation of the IMP and 
IMS. The baseline WBS allows the contractor to develop an 
event-oriented plan that can be translated into a detailed, 
time-dependent, task-oriented schedule. How effectively 
does the baseline WBS allow implementation? The WBS is the 
framework to allow PMs to quickly determine what they are 
doing, how are they going to do it, and when they are 
planning to do it. The baseline WBS contains level 2 
elements that are low-cost and low-risk. They should be 
allocated to the end products. The baseline WBS end 
products are not all end products. They are requirements 
that should be allocated to the high-cost and high-risk end 
products. The baseline WBS does not effectively provide the 
framework to allow PMs to quickly determine what they are 
doing, how are they going to do it, and when are they 
planning to do it. An effective IMP must dociiment the 
significant accomplishments to be completed that lead to a 
key program event. This is difficult to accomplish with the 
Baseline WBS since low-cost, low-risk, high-cost, and high- 
risk elements are all intertwined. If the IMP is not 
effective, then the IMS will most likely not be effective. 
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Therefore, an IMP and IMS developed from the baseline WBS 
does not effectively implement an IMP and IMS. 

8. Alpha Contracting 

Alpha Contracting allows the baseline WBS to be 
developed. Alpha Contracting would allow the Government and 
contractor to address the concerns raised in the above 
paragraphs. Based on my experience, this may result in the 
baseline WBS not being constructed in accordance with MIL- 
HDBK-881. The Government and contractor would jointly 
develop the baseline WBS based on their joint interpretation 
of risks and costs. 

9. Single Process Initiative (SPI) 

The SPI may not allow the baseline WBS to be developed. 
If a contractor has an approved procedure for developing a 
WBS that is not based on MIL-HDBK-881, then the baseline WBS 
would not be developed. Their procedure may result in a 
better or a worse baseline WBS. The WBS may need to be 
negotiated during the solicitation process to ensure that 
the Government will be obtaining useful data with which to 
manage and track the contractor's progress. 

6. DEVELOPMENT OF AN ALTERNATIVE WBS 

An alternative WBS has been developed by the researcher 
based upon: the above analysis, the information presented in 
this thesis, my experience especially from actively 
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participating in Alpha Contracting for award of an EMD 
program and the conversion of the PDRR program, and a 
diagram depicted by Blanchard (1998) in his book entitled 
"Logistics Engineering and Management." The diagram 
depicted a sample WBS which divided the program into two 
projects entitled "Preliminary System Design Phase" and 
"Detailed Design and Development Phase." These are phases 
of an EMD program going through the SEP. This diagram 
divided the program into smaller, more manageable phases or 
projects, versus baseline elements. The alternative WBS is 
based on a program in the EMD acquisition phase. The basic 
concept used to develop the alternate method was to focus on 
the key products and processes that need to be accomplished 
to allow the objectives of an acquisition phase to be 
successfully completed. Then projects were identified for 
each key product and process that needed to be accomplished 
to allow the objectives of the product or process to be 
successfully completed for an EMD program. The alternative 
WBS is shown in Table 4.1. 

Level 1 of the WBS remained unchanged. Level 2 and 
level 3 of the WBS have changed significantly. End product 
parts and enabling product parts are not as easily visible 
with this alternate WBS design; although, the titles of the 
elements allows one to quickly distinguish between them. 

This alternate design is focused on major end products and 
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Level 1 

Level 2 

Level 3 

Aircraft System 

Systems Engineering 
& Integration 

Requirements Management 

Technical Management 

Support Engineering Integration 
Integrated Logistics Support 
Reliability & Maintainability 

Human Systems Integration 
Manufacturing 

Producibility Program 

Quality Assurance 

Requirements Verification 


Program Management 

Program Management 

Business Management 


Airframe 

Airframe Preliminary Design 

Airframe Detailed Design 

Airframe Requirements Verification 
Airframe Manufacturing Process 
Development 


Propulsion 

Propulsion Preliminary Design 
Propulsion Detailed Design 

Propulsion Requirement Verification 
Propulsion Manufacturing Process 
Development 


: Mission Equipment 
Package (MEP) 

MEP Preliminary Design 

MEP Detailed Design 

MEP Requirements Verification 

MEP Manufacturing Process 

Development 


Cockpit 

Cockpit Preliminary Design 

Cockpit Detailed Design 

Cockpit Requirements Verification 
Cockpit Manufacturing Process 
Development 


Hardware Production 

Airframe Production 

Propulsion Production 

MEP Production 

Cockpit Production 


Table 4.1. Alternate WBS (Source: Created by author) 


processes that are key to the success of an EMD program. 

Then projects were identified for each key product and 
process that need to be accomplished to allow the objectives 
of the product or process to be successfully completed for 
an EMD program. One might use a title of Low Rate Initial 
Production (LRIP) Hardware instead of Hardware Production. 

An alternate WBS designed for the PDRR acquisition phase may 
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not have Hardware Production as an element, since one does 
not normally build a significant amount of production-like 
systems for system-level requirements verification 
(testing). In PDRR, you may not have a Component 
Preliminary Design and Detailed Design element. Instead, 
you may have a Component Thirty-Percent Mockup, Seventy- ' 
Percent Mockup, Ninety-Percent Mockup, and Prototype Design 
elements. The concept is to divide the program into smaller 
programs for each design phase or product that is being 
planned during the acquisition phase. 

Based on experience. Air Vehicle is not an element in 
this alternate WBS. An Air Vehicle is composed of an 
Airframe, Propulsion, and MEP which includes Cockpit. The 
Air Vehicle requirements are allocated to those elements or 
products. This allocation is accomplished within the 
Systems Engineering and Integration level 2 element. Thus, 
the Systems Engineering and Integration element is the Air 
Vehicle, but Systems Engineering and Integration more 
clearly depicts the work to be accomplished. 

The level 3 elements of Systems Engineering and 
Integration would also be level 4 elements for each 
Component level 3 elements. For example, the Airframe 
Preliminary Design would contain all the level 3 elements of 
Systems Engineering and Integration except the Manufacturing 


86 



element which may change to be entitled Fabrication, Some 
of the level 3 elements of Systems Engineering and 
Integration may not be included in the Component 
Manufacturing Process Development or their titles may change 
to better indicate the work to be accomplished. 

H. ANALYSIS OF THE ALTERNATE WBS EFFECTIVENESS IN 

IMPLEMENTING ACQUISITION REFORM INITIATIVES 

1. Streamline Acquisition/Adoption of Commercial 
Practices 

The alternate aircraft system WBS allows implementation 
of streamlined acquisition and the adoption of commercial 
practices. As with the baseline WBS, it is very difficult 
to determine the effectiveness of the implementation. Does 
this alternate WBS allow insight versus oversight and help 
reduce cycle-time? 

The total number of level 2 and level 3 elements are 
significantly reduced from fifty-one elements with the 
baseline WBS to thirty-seven elements with the alternate 
WBS. This is a twenty-seven percent reduction. This 
results in less data being submitted by the contractor. 
Therefore, one could make the case that since the contractor 
is presenting less data, there is less insight to the 
program. One should not be concerned with how much data are 
being submitted. They should be concerned with the quality 
and usefulness of the data being submitted. The level 2 and 
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level 3 elements clearly depict the key products and 
processes that need to be accomplished to allow the 
objectives of an EMD program to be successfully completed. 
Risk can be quantified and easily understood for all the 
elements in the alternate WBS. All level 2 and 3 elements 
are usually moderate to high-risk at the start of an EMD 
program. Thus, the number of elements decreased from the 
baseline WBS, but the number of elements with higher risk 
and higher cost significantly increased. This alternate WBS 
will allow the PM to have greater insight into the program 
and lead to early identification of problem areas. The PM 
will be able to implement corrective actions to mitigate 
negative program impacts. 

The next part of the question, does the alternate WBS 
help to reduce cycle-time, is easier to address with the 
alternate WBS. Each product and process should be allocated 
all requirements during the SEP. A tradeoff conducted by 
the Airframe IPT will not impact another component IPT 
unless a requirement is breached. Based on experience, if 
this is the case, the breach or issue is raised back to the 
SEIPT where it is resolved. As with the baseline WBS, the 
potential exists for no communication or miscommunication, 
but this potential has been significantly reduced. Thus, 
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the alternate WBS has the potential of reducing cycle-time, 
especially when compared to the baseline WBS. 

2. Integrated Product and Process Development 
(IPPD)/Integrated Product Team (IPT) 

The alternate WBS is focused on the key product and 
processes that need to be accomplished to allow the 
objectives of an EMD program to be successfully completed. 
IPTs are used to focus on products and processes. Thus, the 
alternate WBS allows implementation of IPTs. How 
effectively are the IPTs structured within the alternate WBS 
and does this IPT structure allow the IPPD process to be 
effectively implemented? As with the baseline WBS analysis, 
another way to ask this question is, does this alternate WBS 
allow functional stovepipes? The alternate WBS 
significantly reduces the potential for the existence of 
functional stovepipes. For example, ILS and HSI are no 
longer divided into several level 2 elements. They are a 
part of the System Engineering and Integration element, as 
well as level 4 elements for each product element. 

Therefore, the SEIPT and each product IPT are held 
accountable (ownership) for satisfying ILS and HIS 
requirements. Each IPT member has a say in the IPPD process 
(Office of the USD(A&T), 1998). Therefore, the probability 
of a functional stovepipe existing is reduced. 
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The alternate WBS is focused on key products and 
processes which require a multi-disciplinary team to develop 
solutions. Also, each of the elements at level 2 can 
function as a miniature project and use IPPD techniques. 
Thus, this alternate WBS does allow for the potential to 
effectively implement IPPD and IPTs. 

3. Cost As An Independent Variable (CAIV) 

The alternate WBS allows for implementation of CAIV. 

How effectively does the alternate WBS implement CAIV? The 
alternate WBS is focused on the key products and processes 
that need to be accomplished to allow the objectives of an 
EMD program to be successfully completed. One can easily 
establish a cost for each element of the alternate WBS. All 
tradeoffs that affect cost are allocated to the product 
element or product IPT. The probability of any tradeoff or 
decision impacting another product element or IPT has been 
significantly reduced. Based on experience, if a breach 
occurs, then the IPT raises it to the SEIPT to resolve. 
Therefore, the alternate WBS significantly increases the 
effectiveness of CAIV implementation. 

4. Total Ownership Costs 

Does the alternate WBS allow programs be managed to 
optimize total system performance and minimize the cost of 
ownership? The alternate WBS is focused on the key products 
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and processes that need to be accomplished to allow the 
objectives of an EMD program to be successfully completed. 
Each product and process should be allocated all 
requirements during the SEP, which includes all costs 
associated to it. The costs include the life-cycle cost or 
total ownership cost. The alternate WBS allows the 
requirements and costs to be clearly identified and 
allocated to an element. Therefore, the alternate WBS 
allows total ownership costs to be effectively allocated and 
used to optimize total system performance and minimize the 
cost of ownership. 

5. Performance Specification 

The alternate WBS allows the use of performance 
specifications. The alternate WBS is focused on the key 
products and processes that need to be accomplished to allow 
the objectives of an EMD program to be successfully 
completed. All requirements are allocated during the SEP to 
each of the level 2 product and process elements. Based on 
experience, the SEIPT maintains the interface control 
documents for the integration of products and processes. If 
the level 2 product and process element breaches their 
allocated requirements, then the issue is raised to the 
SEIPT to resolve. Based on my experience, any level 3 
element breaches are resolved at the respective level 2 
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element. If this level 3 element breach creates a level 2 
element breach, then it is raised to the SEIPT to resolve. 
Thus, this allows performance specifications to be written 
to the elements in the alternate WBS. 

6. Earned Value Management System (EVMS) 

The alternate WBS. allows implementation of the EVMS and 
it allows adequate insight into the high-risk and high-cost 
areas. The alternate WBS allows PMs to quickly determine 
what they are doing, how are they going to do it, and when 
they are planning to do it. The alternate WBS allows an 
EVMS to reflect IPPD and SEP activities. Is the contractor 
or are the IPTs applying the SEP and best practices to 
develop the end products? An EVMS based on the alternate 
WBS will provide PMs with this data. The alternate WBS 
significantly improves the use of the EVMS over that of the 
baseline WBS. 

The program estimates (cost, schedule, performance, and 
risk) are developed at the beginning of an acquisition 
phase. These estimates are based on some amount of 
knowledge and have some degree.of uncertainty. As work is 
accomplished during the acquisition phase, more knowledge is 
being gained that decreases or increases the amount of 
uncertainty in the estimates. An EVMS based on the 
alternate WBS will result in some elements (projects) being 
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closed before the end of the program, similarly to work 
packages. For example, the Airframe Preliminary Design 
element will be closed after the PDR is conducted. A PDR is 
usually conducted after a significant event, which is 
normally some form of a verification (test). At PDR and 
other key events, IPTs should re-evaluate their program 
estimates. Usually, a significant amount of knowledge is 
gained during a phase. This either reduces or increases the 
risk of the next phase, i.e., the Airframe Detailed Design. 
If a Monte Carlo Simulation Tool were used, IPTs will be 
able to review their assximptions and easily modify them to 
reflect the current program. These results should be 
reflected in the EVMS. This process will improve the 
effectiveness of the EVMS. 

7. Integrated Management Plan (IMP) and Integrated 
Memagement Schedule (IMS) 

The alternate WBS allows implementation of the IMP and 
IMS. The alternate WBS allows the contractor to develop an 
event-oriented plan that can be translated into a detailed, 
time-dependent, task-oriented schedule. How effectively 
does the alternate WBS allow implementation? Based on my 
experience, the alternate WBS allows PMs to quickly 
determine what they are doing, how are they going to do it, 
and when they are planning to do it. Based on my 
experience, an IMP based on the alternate WBS will be able 
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to easily document the significant accomplishments that lead 
to a key program event, i.e., a verification event (test). 
Therefore, an IMP and IMS developed from the alternate WBS 
does effectively implement an IMP and IMS. 

8. Alpha Contracting 

Alpha Contracting allows the alternate WBS to be 
developed. Alpha Contracting allows the Government and 
contractor to jointly develop the alternate WBS based upon 
their joint interpretation of risks and costs, although, 
there is a potential for this alternate WBS to not be 
constructed in accordance with paragraph G of this chapter. 

9. Single Process Initiative (SPZ) 

The SPI may not allow the alternate WBS to be 
developed. If a contractor has an approved procedure for 
developing a WBS that is a different concept than the 
alternate WBS concept, then the alternate WBS would not be 
developed. Their procedure may result in a better or worse 
WBS. Again, the WBS may need to be negotiated during the 
solicitation process to ensure the Government and the 
contractor will be obtaining useful data with which to 
manage and track the contractor's progress. 

10. Other Impacts Resulting From the Alternate WBS 

The alternate WBS may result in some negative impacts. 

It will be more difficult to determine the cost of initial 
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spares and repair parts, common and peculiar support 
equipment, training, data, industrial facilities, and 
operational site activation. These elements of the baseline 
WBS are used to support the DoD resource allocation process 
in order to obtain the necessary funding to accomplish 
fielding and operation and support. The information 
required for these elements is allocated and maintained at 
the lower level elements with the alternate WBS. Financial 
personnel will have to search through the data or have the 
IPTs report it to them. There may be other negative impacts 
which requires further analysis. This is beyond the scope 
of this research. 

I. SUMMARY 

The WBS provides a consistent and visible framework for 
communicating cost, schedule, performance, and risk 
management for development of defense materiel items. The 
WBS takes large, complex, unmanageable programs and breaks 
them into small, easily-understandable, and manageable 
modules. PMs need to know what they are doing, how are they 
going to do it, and when they are planning to do it. PMs 
need insight into high-risk and high-cost elements of the 
WBS in order to have successful programs. How a WBS is 
constructed depends on the perspective of the individual IPT 
members. IPTs use the SEP to progressively decompose or 
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allocate system requirements to lower level products and 
processes. 

A baseline WBS was constructed in accordance with MIL- 
HDBK-881. The analysis concluded that this baseline WBS 
significantly impedes DoD implementation of acquisition 
reform initiatives. PMs and IPTs do not have insight into 
the high-risk and high-cost elements. It is difficult to 
determine what we are doing, how are we going to do it, and 
when are we planning to do it. It does not adequately 
identify and differentiate the key products and processes 
essential for program success. 

An alternate WBS was constructed based on the 
analysis of the baseline WBS. The basic concept used to 
develop the alternate method was to focus on the key 
products and processes that need to be accomplished to allow 
the objectives of an acquisition phase to be successfully 
completed. Then projects were identified for each key 
product and process that needed to be accomplished to allow 
the objectives of the product or process to be successfully 
completed for an EMD program. This alternate WBS has the 
potential to significantly facilitate implementation of DoD 
acquisition reform initiatives, although further analysis is 
required to determine all of the impacts. 
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V. CONCLUSIONS AND RECOMMENDATIONS 

A. CONCLUSIONS 

Many of the assertions and conclusions in this thesis 
are based on experiences and discussions with Government and 
contractor personnel during my career. I have attempted to 
implement many acquisition reform initiatives and have been 
frustrated by not being able to effectively execute them. 
Many of the assertions and conclusions in this thesis are a 
result of discussions during IPT meetings and an Alpha 
Contracting process. Additionally, part of the assertions 
and conclusions in this thesis are a result of the various 
acquisition and management courses taken while attending 
NPS. 

1. Primary Question 

To what extent does MIL-HDBK-881 facilitate or impede 

execution of acquisition reform initiatives? 

MIL-HDBK-881 significantly impedes implementation of 
acquisition reform initiatives. A WBS prepared in 
accordance with MIL-HDBK-881 does not allow PMs and IPTs to 
have insight into many of the high-risk and high-cost 
elements. It is difficult to determine what is being 
planned, how it is going to be accomplished, and when it 
will be completed. The WBS does not adequately identify and 
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differentiate the key products and processes essential for 


program success. 

2. Subsidiary Questions 

a) What acquisition reform initiatives does the 
WBS affect? 

The WBS affects the following acquisition reform 
initiatives: 

• Streamlined Acquisition/Adoption of Commercial 
Practices (reduce cycle-time and insight versus 
oversight management) 

• Integrated Product and Process Development 
(IPPD)/Integrated Product Team (IPT) 

• Cost As AN Independent Variable (CAIV) 

• Total Ownership Costs 

• Performance Specification 

• Earned Value Management System (EVMS) 

• Integrated Management Plan (IMP) and Integrated 
Management Schedule (IMS) 

• Alpha Contracting 

• Single Process Initiative 

b) What are the possible uses of the WBS? 

The WBS provides the basis for communication 
throughout the acquisition process. The WBS is used for 
program and technical planning, scheduling, resource 
allocations, cost estimating, budgeting, contracting, 
configuration management, and performance reporting (EVMS). 

c) What does the project manager need to 
consider when structuring a WBS? 

DoD acquisition officials and PMs want to have 

successful programs. They require tools that will allow 
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them to provide the warfighter with an affordable, 
supportable, and operationally-effective and suitable system 
at the time when it is needed. They want to know what they 
are doing, how are they going to do it, and when they are 
planning to do it. They want to ensure proper planning of 
all tasks required to successfully meet the objectives of 
the acquisition phase. They want to know that best 
practices are being logically employed to make their program 
successful. Additionally, they want to know what are the 
high-risk and high-cost areas that will require their 
attention. The WBS is the framework to allow PMs to quickly 
determine what they are doing, how are they going to do it, 
and when they are planning to do it. 

d) Is there an alternative method (s) to 

structure the WBS that will allow better 
execution or implementation of acfjuisition 
reform initiatives? 

Yes, there is an alternate method to structure the 
WBS that could significantly facilitate DoD acquisition 
reform initiatives and increase the effectiveness of the 
EVMS. The basic concept used to develop the alternate 
method was to focus on the key products and processes that 
need to be accomplished to allow the objectives of an 
acquisition phase to be successfully completed. Then 
projects were identified for each key product and process 
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that needs to be accomplished to allow the objectives of the 
product or process to be successfully completed. 

B. RECOMMENDATIONS 

1. Further Study and Analysis of Alternate MBS Format 

This thesis identified an alternate WBS format. This 
alternate WBS has the potential to significantly facilitate 
implementation of acquisition reform initiatives and 
significantly improve the EVMS. This is only a start. It 
requires further study and analysis to determine its 
potential as well as any negative affects. Both Government 
and contractor PMs should be surveyed for their feedback on 
this new method. Data from a prior or existing program 
could be reformatted into the alternate WBS format and 
determine if it is more effective than the actual WBS at 
identifying high-cost and high-risk elements, and early 
identification of potential problems. 

2. Revise MIL-HDBK-881 

MIL-HDBK-881 contradicts itself and I found it 
difficult to follow. It has excellent definitions of 
various elements, but some are confusing. It should be 
revised by using an IPPD environment. Personnel from all 
stakeholders should be on an IPT, for example: acquisition 
managers, systems engineers, financial managers, 
comptrollers, contracting personnel, auditors, etc. The IPT 
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should consist of both Government and contractor personnel. 
Each of their perspectives is essential to determining the 
best technique to construct a WBS that satisfies all of 
their disparate objectives. 

C. RECOMMENDATIONS FOR FURTHER STUDY 

1. Survey Acquisition Community 

Both the Government and contractor acquisition 
communities should be polled to determine their opinions of 
this alternate WBS technique. They should be surveyed to 
determine if they have implementation problems with 
executing acquisition reform initiatives as well as the 
effectiveness of their EVMS. Additionally, they should be 
questioned on any potential negative impacts this alternate 
technique may create. 

2. Convert Prior Program Data 

Data from a prior or existing program should be 
reformatted into the alternate WBS format and determine if 
it is more effective than the actual WBS at identifying 
high-cost and high-risk elements, and early identification 
of potential problems. 
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APPENDIX A. AIRCRAFT SYSTEMS — WORK BREAKDOWN STRUCTURE 

LEVELS 

(Extracted from MIL-HDBK-881) 

A.l. SCOPE 

This appendix provides the aircraft system work 
breakdown structure. Definitions for the aircraft air 
vehicle are provided in this appendix. Definitions for WBS 
elements common to all defense materiel items are given in 
Appendix H: Work Breakdown Structure Definitions, Common 
Elements. 

A. 2. WORK BREAKDOWN STRUCTURE LEVELS 

Table A.l. depicts the Aircraft Systems WBS levels. 

A.3. DEFINITIONS 

A.3.1. Aircraft System 

The complex of equipment (hardware/software), data, 
services, and facilities required to develop and produce air 
vehicles. 

Includes: 

• those employing fixed, movable, rotary, or compound 
wing 

• those manned/unmanned air vehicles designed for 
powered or unpowered (glider) guided flight 
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Level 1 


Aircraft 

System 


_ Level 2 

Air Vehicle (AV) 



Systems 

Engineering/Program 
Management 


System Test and 
Evaluation 


__ Level 3 _ 

Airframe 

Propulsion 

AV Applications Software 
AV System Software 
Communications/Identification 
Navigation/Guidance 
Central Computer 
Fire Control 

Data Display and Controls 
Survivabi1ity 
Reconnaissance 
Automatic Flight Control 
Central Integrated Checkout 
Antisubmarine Warfare 
Weapons Delivery 
Auxiliary Equipment Armament 


Development Test and Evaluation 
Operational Test and Evaluation 
Mock-ups 

Test and Evaluation Support 
Test Facilities 
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Includes: 


airframe, propulsion, and all other installed 
equipment 

design, development, and production of complete 
units -- prototype and operationally configured 
units which satisfy the requirements of their 
applicable specifications, regardless of end use 

Sub-elements to the air vehicle (A.3.2.1 -- 
A.3.2.17) 


A.3.2.1. Airframe 

The assembled structural and aerodynamic 
components of the air vehicle that support subsystems 
essential to designated mission requirements. 

Includes, for example: 

• basic structure -- wing, empennage, fuselage, and 
associated manual flight control system 

• rotary wing pylons, air induction system, thrust 
reversers, thrust vector devices, starters, 
exhausts, fuel management, inlet control system 

• alighting gear — tires, tubes, wheels, brakes, 
hydraulics, etc. 

• secondary power, furnishings — crew, cargo, 
passenger, troop, etc. 

• instruments — flight, navigation, engine, etc. 

• environmental control, life support and personal 
equipment, racks, mounts, intersystem cables and 
distribution boxes, etc., which are inherent to, and 
nonseparable from, the assembled structure 

• dynamic systems -- transmissions, gear boxes, 
propellers, if not furnished as an integral part of 
the propulsion unit 
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• rotor group and other equipment homogeneous to the 
airframe 

In addition to the airframe structure and 
subsystems, this element includes: 


Integration, assembly, test, and checkout: 

Includes: 

• all efforts as identified in Appendix H: Work 
Breakdown Structure Definitions, Common 
Elements, to provide the integration, assembly, 
test, and checkout of all elements into the 
airframe to form the air vehicle as a whole 

• all administrative and technical engineering 
labor to perform integration of level 3 air 
vehicle and airframe elements; development of 
engineering layouts; determination of overall 
design characteristics, and determination of 
requirements of design review 

•• overall air vehicle design and producibility 
engineering 

•• detailed production design; acoustic and 
noise analysis 

•• loads analysis; stress analysis on 

interfacing airframe elements and all 
subsystems 

♦• design maintenance effort and development of 
functional test procedures 

•• coordination of engineering master drawings 
and consultation with test and manufacturing 
groups 

•• tooling planning, design, and fabrication of 
basic and rate tools and functional test 
equipments, as well as the maintenance of 
such equipment 

•• production scheduling and expediting 


106 



•• joining or installation of structures such 
as racks, mounts, etc. 

•• installation of seats, wiring ducting, 
engines, and miscellaneous equipment and 
painting 

•• set up, conduct, and review of testing 

assembled components or subsystems prior to 
installation 

• all effort associated with the installation, 
integration, test, and checkout of the avionic 
systems into the air vehicle including: 

• • design of installation plans 

•• quality assurance planning and control 
including material inspection 

•• installation 

•• recurring verification tests 

• • integration with nonavionics airframe 

subsystems 

• ground checkout prior to flight test; production 
acceptance testing and service review; quality 
assurance activities and the cost of raw 
materials, purchased parts, and purchased 
equipment associated with integration and 
assembly 

Nonrecurring avionics system integration which is associated 
with the individual avionics equipment boxes and avionics 
software in a functioning system. 


Includes: 


the labor required to analyze, design, and 
develop avionics suite interfaces and establish 
interface compatibility with non-avionics 
support equipment systems, aircraft systems, and 
mission planning systems 
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• drawing preparation and establishment of 
avionics interface equipment requirements and 
specifications 

• technical liaison and coordination with the 
military service, subcontractors, associated 
contractors, and test groups 


Excludes: 

• development, testing, and integration of 
software (which should be included in air 
vehicle applications and system software) 

• avionics system testing (included in System Test 
and Evaluation) and aircraft systems engineering 
efforts (included in Systems Engineering/Program 
Management). 

• all effort directly associated with the 
remaining level 3 WBS elements 


A.3.2,2. Propulsion 

That portion of the air vehicle that pertains to 
installed equipment (propulsion unit and other propulsion) 
to provide power/thrust to propel the aircraft through all 
phases of powered flight. 

Includesr for example: 


the engine as a propulsion unit within itself (e.g., 
reciprocating, turbo with or without afterburner, or 
other type propulsion) suitable for integration with 
the airframe 

thrust reversers, thrust vector devices, 
transmissions, gear boxes, and engine control units, 
if furnished as integral to the propulsion unit 

other propulsion equipment required in addition to 
the engine but not furnished as an integral part of 
the engine, such as booster units 
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• the design, development, production, and assembly 
efforts to provide the propulsion unit as an entity 

Excludes: 

• all effort directly associated with the elements and 
the integration, assembly, test, and checkout of 
these elements into the air vehicle 

• all ancillary equipments that are not an integral 
part of the engine required to provide an 
operational primary power source — air inlets, 
instrioments, controls, etc. 


A,3.2.3. Air Vehicle Applications Software 
Includes, for example: 

• all the software that is specifically produced for 
the functional use of a computer system or multiplex 
data base in the air vehicle 

• all effort required to design, develop, integrate, 
and checkout the air vehicle applications Computer 
Software Configuration Items (CSCIs) 

Excludes: 

• the non-software portion of air vehicle firmware 
development and production (ref. ANSI/IEEE Std 
610 . 12 ) 

• software that is an integral part of any specific 
subsystem and software that is related to other WBS 
level 2 elements 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems, 


A.3.2.4. Air Vehicle System Software 

That software designed for a specific computer 
system or family of computer systems to facilitate the 
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operation and maintenance of the computer system and 
associated programs for the air vehicle. 

Includes, for example: 

• operating systems — software that controls the 
execution of programs 

• compilers — computer programs used to translate 
higher order language programs into relocatable or 
absolute machine code equivalents 

• utilities — computer programs or routines designed 
to perform the general support function required by 
other application software, by the operating system, 
or by system users (ref. ANSI/IEEE Std 610.12) 

• all effort required to design, develop, integrate, 
and checkout the air vehicle system software 
including all software developed to support any air 
vehicle applications software development 

• air vehicle system software required to facilitate 
development, integration, and maintenance of any air 
vehicle software build and CSCI 

Excludes: 

• all software that is an integral part of any 
specific subsystem specification or specifically 
designed and developed for system test and 
evaluation 

• software that is an integral part of any specific 
subsystem, and software that is related to other WBS 
level 2 elements 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems, 
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A.3.2.5. Communications/Identification 

That equipment (hardware/software) installed in 
the air vehicle for communications and identification 
purposes. 

Includes, for example: 

• intercoms, radio system(s), identification equipment 
(IFF), data links, and control boxes associated with 
the specific equipment 

• integral communication, navigation, and 
identification package (if used) 

Note 2: All effort directly associated with the 
remaining level 3 ViBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 


A.3.2. 6. Navigation/Guidance 

That equipment (hardware/software) installed in 
the air vehicle to perform the navigational guidance 
function. 

Includes: 

• radar, radio, or other essential navigation 

equipment, radar altimeter, direction finding set, 
doppler compass, computer, and other equipment 
homogeneous to the navigation/guidance function 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 NBS elements and the 
integration, assembly, test, and checkout of 
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these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 


A.3.2.7. Central Ccmputer 

The master data processing unit(s) responsible for 
coordinating and directing the major avionic mission 
systems. 

JNbte 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2i All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 

A.3.2.8. Fire Control 

That equipment (hardware/software) installed in 
the air vehicle which provides the intelligence necessary 
for weapons delivery such as bombing, launching, and firing. 

Includes, for example: 

• radars and other sensors including radomes 

• apertures/antennas, if integral to the fire control 
system, necessary for search, target identification, 
rendezvous and/or tracking 

• self-contained navigation and air data systems • 

• dedicated displays, scopes, or sights 

• bombing computer and control and safety devices 
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Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 

A.3.2.9. Data Display and Controls 

The equipment (hardware/software) which visually 
presents processed data by specially designed electronic 
devices through interconnection (on-or off-line) with 
computer or component equipment and the associated equipment 
needed to control the presentation of the data necessary 
flight and tactical information to the crew for efficient 
management of the aircraft during all segments of the 
mission profile under day and night all-weather conditions. 
Includes, for example: 

• multi-function displays, control display units, 
display processors, and on-board mission planning 
systems 


Excludes: 


• indicators and instrxaments not controlled by 

keyboard via the multiplex data bus and panels and 
consoles which are included under the airframe 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 
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Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 


A.3.2.10. Survivability 

Those equipments (hardware/software) installed in, 
or attached to, the air vehicle which assist in penetration 
for mission accomplishment. 

Includes, for example: 

• ferret and search receivers, warning devices and 
other electronic devices, electronic 
countermeasures, jamming transmitters, chaff, infra¬ 
red jammers, terrain-following radar, and other 
devices typical of this mission function 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 


A.3.2.11. Reconnaissance 

Those equipments {hardware/software) installed in, 
or attached to, the air vehicle necessary to the 
reconnaissance mission. 

Includes, for example: 
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• photographic, electronic, infrared, and other 

sensors 

• search receivers 

• recorders 

• warning devices 

• magazines 

• data link 

Excludes: 

• gun cameras 

Note 1: If lower level Information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems, 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements euid the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier, 

A,3,2,12, Automatic Flight Control 

Those electronic devices and sensors, which, in 
combination with the flight controls subsystem (under 
airframe), enable the crew to control the flight path of the 
aircraft and provide lift, drag, trim, or conversion 
effects. 

Includes, for example: 

• flight control computers, software, signal 
processors, and data transmitting elements that are 
devoted to processing data for either primary or 
automatic flight control functions 

• electronic devices required for signal processing, 
data formatting, and interfacing between the flight 
control elements; the data buses, optical links, and 
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other elements devoted to transmitting flight 
control data 

flight control sensors such as pressure transducers, 
rate gyros, accelerometers, and motion sensors 


Excludes: 

• devices — linkages, control surfaces, and actuating 
devices — covered under the airframe WBS element 

• avionics devices and sensors -- central computers, 
navigation computers, avionics data buses and 
navigation sensors — which are included under other 
avionics WBS elements 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 


A.3.2.13. Central Integrated Checkout 

That equipment (hardware/software) installed in 
the air vehicle for malfunction detection and reporting. 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 
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A,3,2.14. Antisubmarine Warfare 


That equipment (hardware/software) installed in 
the air vehicle peculiar to the antisubmarine warfare 
mission. 

Includes, for example: 

• sensors, computers, displays, etc. 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 


A.3.2.15. Armament 

That equipment (hardware/software) installed in 
the air vehicle to provide the firepower functions. 

Includes, for exasple: 

• guns, high energy weapons, mounts, turrets, weapon 
direction equipment, ammunition feed and ejection 
mechanisms, and gun cameras 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Aut^uated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
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defined in the item specification and provided 
by the supplier. 


A.3.2.16. Weapons Delivery 

That equipment (hardware/software) installed in 
the air vehicle to provide the weapons delivery capability. 

Includes, for example; 

• launchers, pods, bomb racks, pylons, integral 
release mechanisms, and other mechanical or electro¬ 
mechanical equipments specifically oriented to the 
weapons delivery function 

Excludes: 

• bombing/navigation system (included in the fire 
control element) 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 


A.3.2.17. Auxiliary Equipment 

Auxiliary airframe, electronics, and/or 
armament/weapons delivery equipment not allocable to 
individual element equipments, or which provides the 
ancillary functions to the applicable mission equipments. 

Includes, for example: 
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• auxiliary airframe equipment such as external fuel 
tanks, pods, and rotodomes 

• multi-use equipment like antennas, control boxes, 
power supplies, environmental control, racks, and 
mountings, not homogeneous to the prescribed WBS 
elements 

Note 1: If lower level information can be collected, use 
the structure and definitions in Appendix B, 
Electronic/Automated Software Systems. 

Note 2: All effort directly associated with the 
remaining level 3 WBS elements and the 
integration, assembly, test, and checkout of 
these elements into the air vehicle is excluded. 
This item contains embedded software — software 
defined in the item specification and provided 
by the supplier. 

Note 3: Auxiliary armament/weapons delivery equipment 

includes flares and ejection mechanisms, ejector 
cartridges, and other items peculiar to the 
mission function that are not identifiable to 
the armament or weapons delivery elements set 
forth in A.4.2.15 and A.4.2.16 of this appendix. 

A.3 * 3. Common Elements 

WBS Levels 2 and 3. ■ Definitions for common WBS 
elements applicable to the aircraft as well as all other 
defense materiel items are in Appendix H: Work Breakdown 
Structure Definitions, Common Elements. 
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WORK 


APPENDIX B. ELECTRONIC/AUTOMATED SOFTWARE SYSTEMS — 

BREAKDOWN STRUCTURE LEVELS 

(Extracted from MIL-HDBK-881) 


Level 1 

Level 2 

Level 3 

Electronic/ 

Automated 

Software 

System 

Prime Mission Product 
(PMP) 

Subsystem l..n (Specify Names) 

PMP Applications Software 

PMP System Software 

Integration, Assembly, Test and Checkout 


Platform Integration 



Systems 

Engineering/Program 
Management 



System Test and 
Evaluation 

Development Test and Evaluation 
Operational Test and Evaluation 

Mock-ups 

Test and Evaluation Support 

Test Facilities 


Training 

Equipment 

Services 

Facilities 


Data 

Technical Publications 

Engineering Data 

Management Data 

Support Data 

Data Depository 


Peculiar Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Common Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Operational/Site 
Activation 

System Assembly, Installation and 

Checkout on Site 

Contractor Technical Support 

Site Construction 

Site/Ship/Vehicle Conversion 


Industrial Facilities 

Construction/Conversion/Expansion 
Equipment Acquisition or Modernization 
Maintenance (Industrial Facilities) 


Initial Spares and 
Repair Parts 



Table B.l. Electronic/Automated Software Systems WBS (Extracted from MIL-STD-881) 
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APPENDIX C. MISSILE SYSTEM — WORK BREAKDOWN STRUCTURE 

LEVELS 

_(Extracted from MIL-HDBK-881) 


Level 1 

Level 2 

Level 3 

Missile 

System 

Air Vehicle 

Propulsion (Stages I..n,] 

Payload 

Airframe 

Reentry System 

Post Boost System 

Guidance and Control 

Ordnance Initiation Set 

Airborne Test Equipment 

Airborne Training Equipment 

Auxiliary Equipment 

Integration, Assembly, Test and Checkout 


Command and Launch 

Surveillance, Identification and 

Tracking Sensors 

Launch and Guidance Control 

Communications 

Command and Launch Applications 

Software 

Command and Launch System 

Software 

Launcher Equipment 

Auxiliary Equipment 


Systems Engineering/ 
Program Management 



System Test and 
Evaluation 

Development Test and Evaluation 
Operational Test and Evaluation 

Mock-ups 

Test and Evaluation Support 

Test Facilities 


Training 

Equipment 

Services 

Facilities 


Data 

Technical Publications 

Engineering Data 

Management Data 

Support Data 

Data Depository 


Peculiar Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Common Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Operational/Site 
Activation 

System Assembly, Installation and 

Checkout on Site 

Contractor Technical Support 

Site Construction 

Site/Ship/Vehicle Conversion 


Industrial Facilities 

Construction/Conversion/Expansion 

Equipment Acquisition or Modernization 
Maintenance (Industrial Facilities) 


Initial Spares and 
Repair Parts 



Table C.l. Missle System WBS (Extracted from MIL-STD-SSl) 
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APPENDIX D. ORDNANCE SYSTEM — WORK BREAKDOWN STRUCTURE 

LEVELS 

(Extracted from MIL-HDBK-881) 


Level 1 

Level 2 

Level 3 

Ordnance 

System 

Complete Round 

Structure 

Payload 

Guidance and Control 

Fuze 

Safety/Arm 

Propulsion 

Integration, Assembly, Test and Checkout 


Launch System 

Launcher 

Carriage 

Fire Control 

Ready Magazine 

Adapter Kits 

Integration, Assembly, Test and Checkout 


Systems Engineering/ 
Program Management 



System Test and 
Evaluation 

Development Test and Evaluation 
Operational Test and Evaluation 

Mock-ups 

Test and Evaluation Support 

Test Facilities 


Training 

Equipment 

Services 

Facilities 


Data 

Technical Publications 

Engineering Data 

Management Data 

Support Data 

Data Depository 


Peculiar Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Common Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Operational/Site 
Activation 

System Assembly, Installation and 

Checkout on Site 

Contractor Technical Support 

Site Construction 

Site/Ship/Vehicle Conversion 


Industrial Facilities 

C on s t ruc tion/Conversion/Expansion 
Equipment Acquisition or Modernization 
Maintenance (Industrial Facilities) 


Initial Spares and 
Repair Parts 



Table D.l. Ordnance System WBS (Extracted from MIL-STD-881) 
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APPENDIX E. SHIP SYSTEMS — WORK BREAKDOWN STRUCTURE LEVEL 

(Extracted from MIL-HDBK-881) 


Level 1 

Level 2 

Level 3 

Ship System 

Ship 

Hull Structure 

Propulsion Plant 

Electric Plant 

Command and Surveillance 

Auxiliary Systems 

Outfit and Furnishings 

Armament 

Integration/Engineering 

Ship Assembly and Support Services 


Systems Engineering/ 
Program Management 



System Test and 
Evaluation 

Development Test and Evaluation 
Operational Test and Evaluation 

Mock-ups 

Test and Evaluation Support 

Test Facilities 


Training 

Equipment 

Services 

Facilities 


Data 

Technical Publications 

Engineering Data 

Management Data 
' Support Data 

Data Depository 


Peculiar Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Common Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Operational/Site 
Activation 

System Assembly, Installation and 

Checkout on Site 

Contractor Technical Support 

Site Construction 

Site/Ship/Vehicle Conversion 


Industrial Facilities 

C ons true tion/Conver sion/Expansion 

Equipment Acquisition or Modernization 
Maintenance (Industrial Facilities) 


Initial Spares and 
Repair Parts 



Table E.I. Ship Systems WBS (Extracted from MIL-STD-881) 
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APPENDIX F. SPACE SYSTEMS — WORK BREAKDOWN STRUCTURE LEVEL 

(Extracted from MIL-HDBK-881) 


Level 1 

Level 2 

Level 3 

Space 

System 

Launch Vehicle 

Propulsion (Single Stage Only) 

Stage I 

Stage II..n (As Required) 

Strap-On Units (As Required) 

Shroud (Payload Fairing) 

Guidance and Control 

Integration, Assembly, Test and Checkout 


Orbital Transfer 
Vehicle 

Propulsion (Single Stage Only) 

Stage I 

Stage II.,n (As Required) 

Strap-On Units (As Required) 

Guidance and Control 

Integration, Assembly, Test and Checkout 


Space Vehicle 

Spacecraft 

Payload I..n (As Required) 

Reentry Vehicle 

Orbit Injector/Dispenser 

Integration, Assembly, Test and Checkout 


Ground Command, 

Control, 

Communications and 
Mission Equipment 

Sensor I..n (As Required) 

Telemetry, Tracking and Control 

External Communications 

Data Processing Equipment 

Launch Equipment 

Auxiliary Equipment 


Flight Support 
Operations and 

Services 

Mate/Checkout/Launch 

Mission Control 

Tracking and C^ 

Recovery Operations and Services 

Launch Site Maintenance/Refurbishment 


Storage 

Planning and Preparation 

Storage 

Transfer and Transportation 


Systems 

Engineering/Program 
Management 



System Test and 
Evaluation 

Development Test and Evaluation 

Operational Test and Evaluation 

Mock-ups 

Test and Evaluation Support 

Test Facilities 


Training 

Equipment 

Services 

Facilities 


Data 

Technical Publications 

Engineering Data 

Management Data 

Support Data 

Data Depository 


Peculiar Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 
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Coinmon Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Operational/Site 
Activation 

System Assembly, Installation and 
Checkout on Site 

Contractor Technical Support 

Site Construction 

Site/Ship/Vehicle Conversion 


Industrial Facilities 

Cons true tion/Conversion/Expansion 
Equipment Acquisition or Modernization 
Maintenance {Industrial Facilities) 


Initial Spares and 
Repair Parts 



Table E.I. Space Systems WBS (Extracted from MIL-STD-881) 
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WORK BREAKDOWN 


APPENDIX 6. SURFACE VEHICLE SYSTEMS -- 

STRUCTURE LEVEL 

(Extracted from MIL-HDBK-881) 


Level 1 

Level 2 

Level 3 

Surface 

Vehicle 

System 

Primary Vehicle 

Hull/Frame 

Suspension/Steering 

Power Package/Drive Train 

Auxiliary Automotive 

Turret Assembly 

Fire Control 

Armament 

Body/Cab 

Automatic Loading 

Automatic/Remote Piloting 

Nuclear, Biological, Chemical 

Special Equipment 

Navigation 

Communications 

Integration, Assembly, Test and 


Secondary Vehicle 

(Same as Primary Vehicle) 


Systems Engineering/ 
Program Management 



System Test and 
Evaluation 

Development Test and Evaluation 
Operational Test and Evaluation 

Mock-ups 

Test and Evaluation Support 

Test Facilities 


Training 

Equipment 

Services 

Facilities 


Data 

Technical Publications 

Engineering Data 

Management Data 

Support Data 

Data Depository 


Peculiar Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Common Support 
Equipment 

Test and Measurement Equipment 

Support and Handling Equipment 


Operational/Site 
Activation 

System Assembly, Installation and 

Checkout on Site 

Contractor Technical Support 

Site Construction 

Site/Ship/Vehicle Conversion 


Industrial Facilities 

Construction/Conversion/Expansion 
Equipment Acquisition or Modernization 
Maintenance {Industrial Facilities) 


Initial Spares and 
Repair Parts 



Table G.l. Surface Vehicle Systems WBS (Extracted from MIL-STD-881) 
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APPENDIX H. COMMON ELEMENTS — WORK BREAKDOWN STRUCTURE AND 

DEFINITIONS 

(Extracted from MIL-HDBK-881) 

H.l. SCOPE 

This appendix provides the WBS elements common to all 
types of systems. Definitions for the common WBS elements 
are provided in this appendix. 

H.2. DEFINITIONS 

H.2.1. Integration, Assembly, Test, and Checkout 

In those instances in which an integration, assembly, 
test, and checkout element is used (Appendices A through G), 
this element includes all effort of technical and functional 
activities associated with the design, development, and 
production of mating surfaces, structures, equipment, parts, 
materials, and software required to assemble the level 3 
equipment (hardware/software) elements into a level 2 
mission equipment (hardware/software) as a whole and not 
directly part of any other individual level 3 element. 
Includes: 

• the development of engineering layouts, 
determination of overall design characteristics, and 
determination of requirements of design review 

• the set up, conduct, and review of testing assembled 
components or subsystems prior to installation 

• the detailed production design, producibility 
engineering planning (PEP), and manufacturing 
process capability, including the process design 
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development and demonstration effort to achieve 
compatibility with engineering requirements and the 
ability to produce economically and consistent 
quality 

• inspection activities related to receiving, factory 
and vendor liaison 

• design maintenance effort 

• quality planning and control 

• tooling (initial production facilities, factory 
support equipment) including planning, design, and 
fabrication 

• administrative engineering 

• the joining or mating and final assembly of level 3 
equipment elements to form a complete prime mission 
equipment when the effort is performed at the 
manufacturing facility 

• integration of software (including loading and 
verification of firmware) 

• conduct of production acceptance testing 

Excludess 

• all systems engineering/program management and 
system test and evaluation which are associated with 
the overall system 

Note: When an integration, assembly, test, and 

checkout element is utilized at lower levels of 
the contract NBS, it will be summarized into the 
next higher level equipment (hardware/software) 
NBS element and should never be summarized 
directly into a level 3 integration, assembly, 
test, and checkout element. 

H.2.2. Systems Engineering/Program Management 

The systems engineering and technical control as well 
as the business management of particular systems and 
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programs. Systems engineering/program management elements 
to be reported and their levels will be specified by the 
requiring activity. 

Includes: 

• the overall planning, directing, and controlling of 
the definition, development, and production of a 
system or program including supportability and 
acquisition logistics, e.g., maintenance support, 
facilities, personnel, training, testing, and 
activation of a system 

Excludes: 


systems engineering/program management effort that 
can be associated specifically with the equipment 
(hardware/software) element 


H,2,2,1, Systems Engineering 

The technical and management efforts of directing 
and controlling a totally integrated engineering effort of a 
system or program. 

Includes but not limited to: 

• effort to define the system and the integrated 
pls-nning and control of the technical program 
efforts of design engineering, specialty 
engineering, production engineering, and 
integrated test planning 

• effort to transform an operational need or 
statement of deficiency into a description of 
system requirements and a preferred system 
configuration 

• technical planning and control effort for 
planning, monitoring, measuring, evaluating, 
directing, and replanning the management of the 
technical program 
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• (all programs, where applicable) value 
engineering, configuration management, human 
factors, maintainability, reliability, 
survivability/vulnerability, system safety, 
environmental protection, standardization, 
system analysis, logistic support analysis, etc. 

• (for ships) the extended Ship WBS (ESWBS), 
Configuration Management (811) , Hiiman Factors 
(892), Standardization (893), Value Engineering 
(894), and Reliability and Maintainability (895) 
elements 

Excludes: 

• actual design engineering and the production 
engineering directly related to the WBS element 
with which it is associated 

Examples of syst&ns engineering efforts are: 

1) System definition, overall system design, design 
integrity analysis, system optimization, 
system/cost effectiveness analysis, and intra¬ 
system and inter-system compatibility assurance, 
etc.; the integration and balancing of 
reliability, maintainability, producibility, 
safety, human health, environmental protection, 
and survivability; security requirements, 
configuration management and configuration 
control; quality assurance program, value 
engineering, preparation of equipment and 
component performance specifications, design of 
test and demonstration plans; determination of 
software development or software test 
facility/environment requirements. 

2) Preparation of the Systems Engineering 
Management Plan (SEMP), specification tree,^ 
program risk analysis, system planning, decision 
control process, technical performance 
measurement, technical reviews, subcontractor 
and vendor reviews, work authorization, and 
technical documentation control. 

3) Reliability engineering — the engineering 
process and series of tasks required to examine 
the probability of a device or system performing 
its mission adequately for the period of time 
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intended under the operating conditions expected 
to be encountered. 

4) Maintainability engineering -- the engineering 
process and series of tasks required to measure 
the ability of an item or system to be retained 
in or restored to a specified condition of 
readiness, skill levels, etc., using prescribed 
procedures and resources at specific levels of 
maintenance and repair. 

5) Human factors engineering — the engineering 
process and the series of tasks required to 
define, as a comprehensive technical and 
engineering effort, the integration of doctrine, 
manpower, and personnel integration, materiel 
development, operational effectiveness, human 
characteristics, skill capabilities, training, 
manning implication, and other related elements 
into a comprehensive effort. 

6) Supportability analyses — an integral part of 
the systems engineering process beginning at 
program initiation and continuing throughout 
program development. Supportability analyses 
form the basis for related design requirements 
included in the system specification and for 
subsequent decisions concerning how to most cost 
effectively support the system over its entire 
life-cycle. Programs allow contractors the 
maximum flexibility in proposing the most 
appropriate supportability analyses. 


11.2.2.2, Program Management 

The business and administrative planning, 
organizing, directing, coordinating, controlling, and 
approval actions designated to accomplish overall program 
objectives which are not associated with specific hardware 
elements and are not included in systems engineering. 
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Includes for example: 

• cost, schedule, performance measurement management, 
warranty administration, contract management, data 
management, vendor liaison, subcontract management, 
etc. 

• support element management, defined as the logistics 
tasks management effort and technical control, and 
the business management of the support elements. 

The logistics management function encompasses the 
support evaluation and supportability assurance 
required to produce an affordable and supportable 
defense materiel system 

• planning and management of all the functions of 
logistics. Examples are; 

•• maintenance support planning and support 

facilities planning; other support requirements 
determination; support equipment; supply 
support; packaging, handling, storage, and 
transportation; provisioning requirements 
determination and planning; training system 
requirements determination; computer resource 
determination; organizational, intermediate, and 
depot maintenance determination management; and 
data management 

• (for ships) the Extended Ship WBS (ESWBS), Project 
Management (897); Data Management (896); and Supply 
Support (853) elements. 

H.2.3. Sysbem Test and Evaluation 

The use of prototype, production, or specifically 
fabricated hardware/software to obtain or validate 
engineering data on the performance of the system during the 
development phase (normally funded from RDT&E) of the 
program. 

Includes: 

• detailed planning, conduct, support, data reduction 
and reports (excluding the Contract Data 
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Requirements List data) from such testing, and all 
hardware/software items which are consumed or 
planned to be consumed in the conduct of such 
testing 

• all effort associated with the design and production 
of models, specimens, fixtures, and instrumentation 
in support of the system level test program 

Note: Test articles which are complete units (i.e., 

functionally configured as required by 
specifications) are excluded from this vms 
element. 

Excludes: 

• all formal and informal testing up through the 
subsystem level which can be associated with the 
hardware/software element 

• acceptance testing 

Note: These excluded efforts are to be included with 

the appropriate hardware or software elements. 


H.2.3.1. Development Test and Evaluation 

This effort is planned, conducted and monitored by 
the developing agency of the DoD component. It includes 
test and evaluation conducted to: 

• demonstrate that the engineering design and 
development process is complete. 

• demonstrate that the design risks have been 
minimized. 

• demonstrate that the system will meet 
specifications. 

• estimate the system's military utility when 
introduced. 
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• determine whether the engineering design is 
supportable (practical, maintainable, safe, etc.) 
for operational use. 

• provide test data with which to examine and evaluate 
trade-offs against specification requirements, life- 
cycle cost, and schedule. 

• perform the logistics testing efforts to evaluate 
the achievement of supportability goals, the 
adequacy of the support package for the system, 

(e.g., deliverable maintenance tools, test 
equipment, technical publications, maintenance 
instructions, and personnel skills and training 
requirements, etc.). 

Includes, for example: 

• all contractor in-house effort 

• (all programs, where applicable) models, tests and 
associated simulations such as wind tunnel, static, 
drop, and fatigue; integration ground tests; test 
bed aircraft and associated support; qualification 
test and evaluation, development flight test, test 
instriamentation, environmental tests, ballistics, 
radiological, range and accuracy demonstrations, 
test facility operations, test equipment (including 
its support equipment), chase and calibrated pacer 
aircraft and support thereto, and logistics testing 

• (for aircraft) avionics integration test composed of 
the following: 

•• test bench/laboratory, including design, 

acquisition, and installation of basic computers 
and test equipments which will provide an 
ability to simulate in the laboratory the 
operational environment of the avionics 
system/subsystem 

•• air vehicle equipment, consisting of the 

avionics and/or other air vehicle subsystem 
modules which are required by the bench/lab or 
flying test bed in order to provide a compatible 
airframe avionics system/subsystem for 
evaluation purposes 
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•• flying test bed, including requirements 

analysis, design of modifications, lease or 
purchase of test bed aircraft, modification of 
aircraft, installation of avionics equipment and 
instrumentation, and checkout of an existing 
aircraft used essentially as a flying avionics 
laboratory 

•• avionics test program, consisting of the effort 
required to develop test plans/procedures, 
conduct tests, and analyze hardware and software 
test results to verify the avionics equipments' 
operational capability and compatibility as an 
integrated air vehicle subsystem 

•• software, referring to the effort required to 
design, code, de-bug, and document software 
programs necessary to direct the avionics 
integration test 

(for engines) engine military qualification tests 
and engine preliminary flight rating tests 

(for ships) model basin, hydrostatic, fatigue, 
shock, special sea tests and trials, etc., including 
the Extended Ship WBS (ESWBS), Trials Agenda 
Preparation, Data Collection & Analysis (842); Dock 
and Sea Trials (9823); and Hull Vibration Survey 
(9825) elements 


11,2,3.2. Opsrational Test and Evaluation 

The test and evaluation conducted by agencies 
other than the developing command to assess the prospective 
system's military utility, operational effectiveness, 
operational suitability, logistics supportability (including 
compatibility, inter-operability, reliability, 
maintainability, logistic requirements, etc.), cost of 
ownership, and need for any modifications. 
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Includes, for example: 


Initial operational test and evaluation conducted 
during the development of a weapon system 

such tests as system demonstration, flight tests, 
sea trials, mobility demonstrations, on-orbit tests, 
spin demonstration, stability tests, qualification 
operational test and evaluation, etc., and support 
thereto, required to prove the operational 
capability of the deliverable system 

contractor support (e.g., technical assistance, 
maintenance, labor, material, etc.) consumed during 
this phase of testing 

logistics testing efforts to evaluate the 
achievement of supportability goals and the adequacy 
of the support for the system (e.g., deliverable 
maintenance tools, test equipment, technical 
publications, maintenance instructions, personnel 
skills and training requirements, and software 
support facility/environment elements) 


H.2,3.3. Mock-Ups 

The design engineering and production of system or 
subsystem mock-ups which have special contractual or 
engineering significance, or which are not required solely 
for the conduct of one of the above elements of testing. 


E.2.3.4. Test and Evaluation Support 

The support elements necessary to operate and 
maintain, during test and evaluation, systems and subsystems 
which are not consumed during the testing phase and are not 
allocated to a specific phase of testing. 
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Includes, for example: 


• repairable spares, repair of repairable, repair 
parts, warehousing and distribution of spares and 
repair parts, test and support equipment, test bed 
vehicles, drones, surveillance aircraft, tracking 
vessels, contractor technical support, etc. 

Excludes: 

• operational and maintenance personnel, consumables, 
special fixtures, special instrumentation, etc., 
which are utilized and/or cons^amed in a single 
element of testing and which should be included 
under that element of testing 


H.2,3.5. Test Facilities 

The special test facilities required for 
performance of the various developmental tests necessary to 
prove the design and reliability of the system or subsystem. 

Includes, for example: 

• test tank test fixtures, propulsion test fixtures, 
white rooms, test chambers, etc. 

Excludes: 

• brick and mortar-type facilities identified as 
industrial facilities 

H. 2.4. Training 

Deliverable training services, devices, accessories, 
aids, equipment, and parts used to facilitate instruction 
through which personnel will learn to operate and maintain 
the system with maximum efficiency. 
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Includes: 


• all effort associated with the design, development, 
and production of deliverable training equipment as 
well as the execution of training services 

Excludes: 

• overall planning, management, and task analysis 
function inherent in the WBS element Systems 
Engineering/Program Management 


H.2,4.1. Equipment 

Distinctive deliverable end items of training 
equipment, assigned by either a contractor or military 
service, required to meet specific training objectives. 

Includes, for example: 

• operational trainers, maintenance trainers, and 

other items such as cutaways, mock-ups, and models 


H.2,4.2. Services 

Deliverable services, accessories, and aids 
necessary to accomplish the objectives of training. 

Includes: 

• training course materials; contractor-conducted 
training (in-plant and service training); and the 
materials and curriculum required to design, 
execute, and produce a contractor developed training 
program 

• materiel, courses, and associated docxunentation 
(primarily the computer software, courses and 
training aids) 


144 




Excludes: 


• deliverable training data associated with the WBS 
element Support Data 


H.2,4.3. Facilities 

The special construction necessary to accomplish 
training objectives. 

Includes, for exas^le: 

• modification or rehabilitation of existing 
facilities used to accomplish training objectives 

Excludes: 

• installed equipment used to acquaint the trainee 
with the system or establish trainee proficiency 

• the brick and mortar-type facilities identified as 
industrial facilities 

H•2•5• Data 

The deliverable data required to be listed on a 
Contract Data Requirements List, DD Form 1423. 

Includes: 

• only such effort that can be reduced or avoided if 
the data item is eliminated 

• (government-peculiar data) acquiring, writing, 
assembling, reproducing, packaging and shipping the 
data 

• transforming into government format, reproducing and 
shipping data identical to that used by the 
contractor but in a different format 
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H.2.5.1. Technical Publications 

Technical data, providing instructions for 
installation, operation, maintenance, training, and support, 
formatted into a technical manual. Data may be presented in 
any form (regardless of the form or method of recording), 
Technical orders that meet the criteria of this definition 
may also be classified as technical manuals. 

Includes, for example: 

• operation and maintenance instructions, parts lists 
or parts breakdown, and related technical 
information or procedures exclusive of 
administrative procedures 

• data item descriptions set forth in categories 
selected from the Acquisition Management Systems and 
Data Requirements Control List (DoD Regulation 
5010.12-L) 

• (for ships) Extended Ship WBS (ESWBS), Technical 
Manuals and Other Data (856) element 

H.2.5.2. Engineering Data 

Recorded scientific or technical information 
(regardless of the form or method of recording) including 
computer software documentation. Engineering data defines 
and documents an engineering design or product configuration 
(sufficient to allow duplication of the original items) and 
is used to support production, engineering and logistics 
activities. 
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Includes, for example: 

• all final plans, procedures, reports, and 
documentation pertaining to systems, subsystems, 
computer and computer resource programs, component 
engineering, operational testing, hximan factors, 
reliability, availability, and maintainability, and 
other engineering analysis, etc. 

• Technical data package (reprocurement package) which 
includes all engineering drawings, associated lists, 
process descriptions, and other documents defining 
physical geometry, material composition, and 
performance procedures 

• (for' ships) Extended Ship WBS (ESWBS), Design 
Support, Ship's Selected Records (8302); Design 
Support, Services, Reproduction (8303); and 
Engineering Drawings and Specifications (855) 
elements 

Excludes: 

• computer software or financial, administrative, cost 
or pricing, or management data or other information 
incidental to contract administration 


H.2.5.3. Management Data 

The data items necessary for configuration 
management, cost, schedule, contractual data management, 
program management, etc., required by the government in 
accordance with functional categories selected from the 
DODISS and DoD Regulation 5010.12-L. 

Includes, for example: 

• contractor cost reports, cost performance reports, 
contract funds status reports, schedules, 
milestones, networks, integrated support plans, etc. 

• (for ships) Extended Ship WBS (ESWBS), Contract Data 
Requirements (988) element 
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H.2.5.4. Support Data 

The data items designed to document support 
planning in accordance with functional categories selected 
from DoD Regulation 5010.12-L. 

Includes, for example: 

• supply; general maintenance plans and reports; 

training data; transportation, handling, storage, 
and packaging information; facilities data; data to 
support the provisioning process and all other 
support data; and software supportability planning 
and software support transition planning docxaments. 


H.2.5.5. Data Depository 

The facility designated to act as custodian to 
maintain a master engineering specification and establish a 
drawing depository service for government approved documents 
that are the property of the U.S. Government. As custodian 
for the government, the depository, authorized by approved 
change orders, maintains these master docxaments at the 
latest approved revision level. This facility is a distinct 
entity. 

Includes, for example: 

• all drafting and clerical effort necessary to 
maintain docxaments 

Excludes: 

• all similar effort for facility's specification and 
drawing control system, in support of its 
engineering and production activities. 


148 




Note: 


nben documentation is called for on a given item 
of data retained in the depository, the charges 
(if charged as direct) will be to the 
appropriate data element. 

H.2.6. Peculiar Support Equipment 

The design, development, and production of those 
deliverable items and associated software required to 
support and maintain the system or portions of the system 
while the system is not directly engaged in the performance 
of its mission, and which are not common support equipment 
(See H.3.7 below). 

Includes: 

• vehicles, equipment, tools, etc., used to fuel, 
service, transport, hoist, repair, overhaul, 
assemble, disassemble, test, inspect, or otherwise 
maintain mission equipment 

• any production of duplicate or modified factory test 
or tooling equipment delivered to the government for 
use in maintaining the system. (Factory test and 
tooling equipment initially used by the contractor 
in the production process but subsequently delivered 
to the government will be included as cost of the 
item produced.) 

• any additional equipment or software required to 
maintain or modify the software portions of the 
system 

Excludes: 

• overall planning, management and task analysis 
functions inherent in the WBS element. Systems 
Engineering/Program Management 

• common support equipment, presently in the DoD 
inventory or commercially available, bought by the 
using command, not by the acquiring command 
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H.2.6.1. Test and Measurement Equipment 

The peculiar or unique testing and measurement 
equipment which allows an operator or maintenance function 
to evaluate operational conditions of a system or equipment 
by performing specific diagnostics, screening or quality 
assurance effort at an organizational, intermediate, or 
depot level of equipment support. 

Includes, for exarple: 

• test measurement and diagnostic equipment, precision 
measuring equipment, automatic test equipment, 
manual test equipment, automatic test systems, test 
program sets, appropriate interconnect devices, 
automated load modules, taps, and related software, 
firmware and support hardware (power supply 
equipment, etc.) used at all levels of maintenance 

• packages which enable line or shop replaceable 
units, printed circuit boards, or similar items to 
be diagnosed using automatic test equipment 


H.2.6,2, Support and Handling Equipment 

The deliverable tools and handling equipment used 
for support of the mission system. 

Includes, for exarple: 

• ground support equipment, vehicular support 

equipment, powered support equipment, nonpowered 
support equipment, munitions material handling 
equipment, materiel handling equipment, and software 
support equipment (hardware and software) 

H.2.7. Common Support Equipment 

The items required to support and maintain the system 
or portions of the system while not directly engaged in the 
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performance of its mission, and which are presently in the 
DoD inventory for support of other systems. 

Includes: 

• acquisition of additional quantities of this 
equipment needed to support the item 

• all efforts required to assure the availability of 
this equipment to support the item 


H.2,7Test and Measurement E<iuipment 

The common testing and measurement equipment which 


allows an operator or maintenance function to evaluate 
operational conditions of a system or equipment by 
performing specific diagnostics, screening or quality 
assurance effort at an organizational, intermediate, or 
depot level of equipment support. 

Includes, for exeunple: 

• test measurement and diagnostic equipment, precision 
measuring equipment, automatic test equipment, 
manual test equipment, automatic test systems, test 

sets, appropriate interconnect devices, 
automated load modules, taps, and related software, 
firmware and support hardware (power supply 
6<5uipnisnt, etc.) used at all levels of maintenance 

• packages which enable line or shop replaceable 
units, printed circuit boards, or similar items to 
be diagnosed using automatic test equipment 


H.2.7,2, Support and Handling Eguipment 

The deliverable tools and handling equipment used 
for support of the mission system. 
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Includes, for example: 

• ground support equipment, vehicular support 
equipment, powered support equipment, nonpowered 
support equipment, munitions material handling 
equipment, materiel handling equipment, and software 
support equipment (hardware/software) 

H.2.8. Operatioixal/Site Activation 

The real estate, construction, conversion, utilities, 
and equipment to provide all facilities required to house, 
service, and launch prime mission equipment at the 
organizational and intermediate level. 

Includes: 

• conversion of site, ship, or vehicle 

• system assembly, checkout, and installation (of 
mission and support equipment) into site facility or 
ship to achieve operational status 

• contractor support in relation to operational/site 
aestivation 


H.2.8.1. System Assembly, Installation, and 
Checkout on Site 

The materials and services involved in the 
assembly of mission equipment at the site. 

Includes, for example: 

• installation of mission and support equipment in the 
operations or support facilities and complete system 
checkout or shakedown to ensure operational status. 
(Where appropriate, specify by site, ship or 
vehicle.) 
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K.2.8.2. Contractor Technical Support 

The materials and services provided by the 
contractor related to activation. 

Includes, for examples 

• repair of repairable, standby services, final 
turnover, etc. 

H.2,8.3, Site Construction 

Real estate, site planning and preparation, 
construction, and other special-purpose facilities necessary 
to achieve system operational status. 

Includes, for example: 

• construction of utilities, roads, and 
interconnecting cabling 

H.2.8.4. Site/Ship/Vehicle Conversion 

The materials and services required to convert 
existing sites, ships, or vehicles to accommodate the 
mission equipment and selected support equipment directly 
related to the specific system. 

Includes, for examples 

• operations, support, and other special purpose 
(e.g., launch) facilities conversion necessary to 
achieve system operational status. (Where 
appropriate, specify by site, ship or vehicle.) 

H.2.9. Industrial Facilities 

The construction, conversion, or expansion of 
industrial facilities for production, inventory, and 
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contractor depot maintenance required when that service is 
for the specific system. 


Includes: 

• equipment acquisition or modernization, where 
applicable 

• maintenance of these facilities or equipment 

• industrial facilities for hazardous waste management 
to satisfy environmental standards 

H.2,9.1. Construction/Conversion/Expansion 

The real estate and preparation of system peculiar 
industrial facilities for production, inventory, depot 
maintenance, and other related activities. 

H.2.9,2. Equipment Acquisition or Modernization 

The production equipment acquisition, 
modernization, or transferal of equipment for the particular 
system. (Pertains to government owned and leased equipment 
under facilities contract.) 

H.2,9.3, Maintenance (Industrial Facilities) 

The maintenance, preservation, and repair of 
industrial facilities and equipment. 

H.2.10. Initial Spares emd Repair Parts 

The deliverable spare components, assemblies and 
subassemblies used for initial replacement purposes in the 
materiel system equipment end item. 

Includes: 
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repairable spares and repair parts required as 
initial stockage to support and maintain newly- 
fielded systems or subsystems during the initial 
phase of service, including pipeline and war reserve 
quantities, at all levels of maintenance and support 


Excludes: 


• development test spares and spares provided 
specifically for use during installation, assembly, and 
checkout on site. Lower level WBS elements should be by 
subsystem. 
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APPENDIX I. SYSTEMS ENGINEERING PROCESS OVERVIEW 


(Extracted from DSMC, Systems Engineering Fundamentals) 

1.1. THE PROCESS 

The Systems Engineering Process (SEP) is a 
comprehensive, iterative and recursive problem solving 
process, applied sequentially top-down by integrated teams. 
It transforms needs and requirements into a set of system 
product and process descriptions, generate information for 
decision-makers, and provides input for the next level of 
development. The process is applied sequentially, one level 
at a time, adding additional detail and definition with each 
level of development. As shown by Figure I-l, the process 
includes inputs and out-puts, requirements analysis, 
functional analysis and allocation, requirements loop, 
synthesis, design loop, verification, and system analysis 
and control. 

1.2. SE PROCESS INPUTS 

Inputs consist primarily of the customer's needs, 
objectives, requirements and project constraints. Inputs 
can include, but are not restricted to, missions, measures 
of effectiveness, environments, available technology base, 
output requirements from prior application of the systems 
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engineering process, program decision requirements, and 
requirements based on "corporate knowledge." 


Procass Input 

• CustormrNMcb'ObjectfVM/ 
Requirem»nt8 

- Missions 

- Msssurss of Effsctivsnsss 
« Environmsnts 

ConstTsinfs 

• Technology Base 

• Output Rsquiremsntt from Prior 
Oevelopmo^ Effort 

• Program Decision Requirements ^ 
■ Requirements Applied Through ^ 

Spectfieations and Standards 


Requirements Analysis 

• Analyse Missions & Environments 

• Identify Functional Requiremants 

• Oefine^firte Performanee & Design 
Constraint Requirements 

SRvffiBSHS!!! 






Requirements Loop 



Functional AnalysIs^Allocatlon 

• Decompose to Lower*Level Functions 

• Alocate Performance A Other Limiting Requirements to^ 
Al Funotionai Levels 

• Defoie^efine Functional Interfaces (Intemal^ernaO 

• Oefin^efine/lntegrate Functional Architecture 


• Trade-Off Studiee 

• Effectiveness Analyses 

• Risk Management 
Configuration Management 

• Interfeoe Management 

• Data Management 
Performance Measurement 

-SEMS 

-TPM 

- Technical Reviews 


Design Loop 


VerHicatlon 


W 


Synthssls 

• Transform Ardiitectuies (Functional to Physical} 

« Define AKemative System Concepts, Configuration 
hems & System Elements 

• Select Preferred Product & Procees Solutione 

• Define/Reflne Physical Interfaces (Intemal/Extemal) 


Rslatsd Terms: 

Customer! 
Primary Functions« 

Systarm Elements > 




Organizations responsaMe for Primary Funcrk>ns 
Developmsnt, ProduotioiVConstruclion, Ve ifieation, 
Deptoynwnt Operations, Support, Training, Disposal 
Hardware, Software, Personnel, Facilities, Data, Material, 
Services, Techniques 


Process Output 

• E>evelopment Level Dependent 

- Decision Date Base 
-SyatenVConfiguration Item 

Architecture 

- Specifieations A Besetines 


Figure I.l. The Systems Engineering Process 


1.3. REQUIREMENTS ANALYSIS 

The first step of the Systems Engineering Process is to 
analyze the process inputs. Requirements analysis is used 
to develop functional and performance requirements; that is, 
customer requirements are translated into a set of 
requirements that define what the system must do and how 

s.^ 

well it must perform. The systems engineer must ensure that 
the requirements are understandable, unambiguous, 
comprehensive, complete, and concise. Requirements analysis 
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must clarify and define functional requirements and design 
constraints. Functional requirements define quantity (how 
many), quality (how good), coverage (how far), time lines 
(when and how long), and availability (how often.) Design 
constraints define those factors that limit design 
flexibility, such as environmental conditions or limits, 
defense against internal or external threats, contract, 
customer or regulatory standards. 

1.4. FUNCTIONAL ANALYSIS/ALLOCATZON 

Functions are analyzed by decomposing higher-level 
functions identified through requirements analysis into 
lower-level functions. The performance requirements 
associated with the higher level are allocated to lower 
functions. The result is a description of the product or 
item in terms of what it does logically and in terms of the 
performance required. This description is often called the 
functional architecture of the product or item. Functional 
analysis and allocation allows for a better understanding of 
what the system has to do, in what ways it can do it, and to 
some extent, the priorities and conflicts associated with 
lower-level functions. It provides information essential to 
optimizing physical solutions. Key tools in functional 
analysis and allocation are Functional Flow Block Diagrams, 
Time Line Analysis, and the Requirements Allocation Sheet. 
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1.5. REQUIREMENTS LOOP 

Performance of the functional analysis and allocation 
results in a better understanding of the requirements and 
should prompt reconsideration of the requirements analysis. 
Each function identified should be traceable back to a 
requirement. This iterative process of revisiting 
requirements analysis as a result of functional analysis and 
allocation is referred to as the requirements loop. 

1.6. DESIGN SYNTHESIS 

Design synthesis is the process of defining the product 
or item in terms of the physical and software elements which 
together make up and define the item. The result is often 
referred to as the physical architecture. Each part must 
meet at least one functional requirement, and any part may 
support many functions. The physical architecture is the 
basic structure for generating the specifications and 
baselines. 

1.7. DESIGN LOOP 

Similar to the requirements loop described above, the 
design loop is the process of revisiting the functional 
architecture to verify that the physical design synthesized 
can perform the required functions at required levels of 
performance. The design loop pe 2 rmits reconsideration of how 
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the system will perform its mission, and this helps optimize 
the synthesized design. 

1.8. VERIFICATION 

For each application of the system engineering process, 
the solution will be compared to the requirements. This 
part of the process is called the verification loop, or more 
commonly. Verification. Each requirement at each level of 
development must be verifiable. Baseline documentation 
developed during the systems engineering process must 
establish the method of verification for each requirement. 
Appropriate methods of verification include examination, 
demonstration, analysis (including modeling and simulation), 
and testing. Formal test and evaluation (both developmental 
and operational) are important contributors to the 
verification of systems. 

1.9. SYSTEMS ANALYSIS AND CONTROL 

Systems Analysis and Control include technical 
management activities required to measure progress, evaluate 
and select alternatives, and docximent data and decisions. 
These activities apply to all steps of the SE process. 

System analysis activities include trade-off studies, 
effectiveness analyses, and design analyses. They evaluate 
alternative approaches to satisfy technical requirements and 
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program objectives, and provide a rigorous quantitative 
basis for selecting performance, functional, and design 
requirements. Tools used to provide input to analysis 
activities include modeling, simulation, experimentation, 
and test. Control activities include risk management, 
configuration management, data management, and performance- 
based progress measurement including event based scheduling. 
Technical Performance Measurement (TPM), and technical 
reviews. The purpose of Systems Analysis and Control is to 
ensure that: 


• Solution alternative decisions are made only after 
evaluating the impact on system effectiveness, life- 
cycle resources, risk, and customer requirements; 

• Technical decisions and specification requirements 
are based on systems engineering outputs; 

• Traceability from systems engineering process inputs 
to outputs is maintained; 

• Schedules for development and delivery are mutually 
supportive; 

• Required technical disciplines are integrated into 
the systems engineering effort; 

• Impacts of customer requirements on resulting 
functional and performance requirements are examined 
for validity, consistency, desirability, and 
attainability; and; 

• Product and process design requirements are directly 
traceable to the functional and performance 
requirements they were designed to fulfill, and vice 
versa. 
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I.10. SE PROCESS OUTPUT 

Process output is dependent on the level of 
development. It will include the decision database, the 
system or configuration item architecture, and the 
baselines, including specifications, appropriate to the 
phase of development. In general, it is any data that 
describes or controls the product configuration or the 
processes necessary to develop that product. 
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